geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-73) Remove old rolling-upgrade methods and code
Date Tue, 02 Feb 2016 21:58:39 GMT


ASF subversion and git services commented on GEODE-73:

Commit f7b2714c14a6eeab4e810a85f65d650483f2ce6f in incubator-geode's branch refs/heads/develop
from [~bschuchardt]
[;h=f7b2714 ]

GEODE-73: Removing unnecessary P2P backward-compatibility serialization code

Geode 1.0 will not be backward-compatible with GemFire 8.X (and older) peers
due to upgrading to Apache 2.0 licensed JGroups.  This removes the
serialization code that maintained that backward-compatibility.

This does not remove backward-compatibility code for client/server
communications, so older GemFire clients can still be used with Geode 1.0.

> Remove old rolling-upgrade methods and code
> -------------------------------------------
>                 Key: GEODE-73
>                 URL:
>             Project: Geode
>          Issue Type: Improvement
>    Affects Versions: 1.0.0-incubating
>            Reporter: Bruce Schuchardt
>            Assignee: Bruce Schuchardt
>              Labels: cleanup, docs
> 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

View raw message