I've updated the Jira to only request removal of peer-to-peer
backward-compatibility code, preserving the ability for someone to jump
in with a solution for GemFire clients to migrate to using a Geode-based
server cluster. Further discussion on this topic is, as I understand
it, moving to a Pivotal email list.
Le 7/1/2015 5:24 PM, John Knapp a écrit :
Have we looked at what it would take to build a facade in GemFire to
maintain the Gemstone packaging but actually referencing the new Geode
structures? We could depreciate the totality of the facade as a way to
signal to existing enterprise customers that they need to start migrating.
Granted it is alot of shell code but addresses Mike's point about
enterprise customer revolt and give a graceful way to get customers off of
the gemstone packages in the future.
John
On Wed, Jul 1, 2015 at 7:17 PM, Sudhir Menon <[email protected]> wrote:
Mike,
If the product has to be based on Geode, then we just take Geode as built
in the open, package up the GemFire add-ons and ship it. Any attempt to
take in the source code, process it and change it etc. will beat the whole
point and introduce too many unintended consequences. I would not prefer
this option. Our customer want open source core, thats what we give them,
because otherwise we have not dealt with the vendor lock in issue that open
source renders irrelevant.
Suds
On Wed, Jul 1, 2015 at 1:54 PM, Michael Stolz <[email protected]> wrote:
I have already suggested that we go ahead and do all the re-packaging for
Geode, but that before we build the enterprise version we use a
pre-processing script that automatically re-packages all org.Apache.Geode
to com.Gemstone.Gemfire as part of the build process so that WE eat the
difficulty of the necessary open-source re-packaging rather than hundreds
of customers with millions of lines of code that they would need to
change.
--
Mike Stolz
Principal Technical Account Manager
Mobile: 631-835-4771
On Wed, Jul 1, 2015 at 4:16 PM, Bruce Schuchardt <[email protected]
wrote:
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.
--
Suds Menon
Head of Products (Real Time & Big Data)
503-724-1481 (c)
For
prompt responses to questions
on GemFire/SQLFire, please write to
rtds-dev-ea at gopivotal dot com
