[
https://issues.apache.org/jira/browse/GEODE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14612329#comment-14612329
]
Bruce Schuchardt commented on GEODE-73:
---------------------------------------
In the spirit of wanting the largest user-base possible for Geode I want to
amend this Jira based on discussions on the geode-dev mailing list.
While replacement of the 2.2.9 JGroups implementation with a newer version or
possibly using a different clustering solution will break the ability to
perform rolling upgrade for servers it may be that old GemFire clients will be
able to use a Geode cluster, especially if packages aren't renamed from their
current com.gemstone.gemfire prefix to org.apache.geode, or if an SPI is
inserted into BaseCommand to allow replacement of org.apache.geode based
exceptions with com.gemstone.gemfire equivalents in writeException() for old
clients.
To that end we should only remove the backward compatibility code from
DistributionMessage subclasses and cache operation classes that are
accommodating old distributed algorithms (i.e., InitialImageOperation).
> Remove old rolling-upgrade methods and code
> -------------------------------------------
>
> Key: GEODE-73
> URL: https://issues.apache.org/jira/browse/GEODE-73
> Project: Geode
> Issue Type: Improvement
> Affects Versions: 1.0.0-incubating
> Reporter: Bruce Schuchardt
> Labels: cleanup
>
> Geode supports rolling upgrade between major and minor versions. This is a
> really cool feature that should be kept up, but there are a lot of
> serialization methods that are checking for old versions of GemFire in the
> code that ought to be removed. These have the form
> toDataPre_GFE_major_minor_patch_build()
> fromDataPre_GFE_major_minor_patch_build()
> These methods are no longer needed since rolling upgrade isn't going to be
> possible from old GemFire processes to Geode. Also, old GemFire clients
> won't be supported either due to the package renaming that needs to take
> place.
> Aside from these methods there are other places that are checking to see what
> version is attached to a DataInput or DataOutput using
> InternalDataSerializer.getVersionForDataStream[OrNull], or are using the
> getVersionObject() method in InternalDistributedMember to make decisions
> about how to deal with old GemFire members. Care needs to be taken here
> since some uses of these methods are to set up proper serialization in
> HeapDataOutputStreams.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
