Mike, this seems like something to bring up with GemFire product management.
As I understand it the main problem for client/server is that there are
some objects, especially exceptions, that are transmitted via java
serialization and the package renaming is going to break compatibility.
For data-serialization we can swizzle package names but that's not
possible for plain old java serialization.
For peer-to-peer it is also going to be broken because we can't use the
old 2.2.9 version of JGroups and make it out of incubation. Newer
versions of JGroups are on-wire incompatible with 2.2.9.
Le 7/1/2015 12:50 PM, Michael Stolz a écrit :
This notion of propagating a breaking change to all Enterprise users is
going to be extremely traumatic.
Customers are already raising their voices about them having to endure a
breaking change to THEIR CODE for the sake of the opensource version being
made available for free totally unacceptable.
We MUST find a way to keep the Enterprise version backward compatible or we
risk a wholesale migration of enterprise customers to other solutions.
--
Mike Stolz
Principal Technical Account Manager
Mobile: 631-835-4771
On Jul 1, 2015 12:10 PM, "Bruce Schuchardt" <[email protected]> wrote:
Geode-72 <https://issues.apache.org/jira/browse/GEODE-72> calls for
removing rolling upgrade code for old GemFire releases. There's no reason
for Geode code to be cluttered up with rolling upgrade code for old GemFire
releases since you won't be able to do a rolling upgrade from those
releases to Geode due to package renaming.
