For backwards compatibility I see at least two levels of compatibility: 1. client compatibility: can an old client work with a new server? 2. code compatibility: can old code be used as is with the new product? a. class compatibility: can I use my already compiled old classes/jars with the new product? b. source compatibility: can I use my already written code, after recompiling it with the new product?
On Wed, Sep 2, 2015 at 2:38 PM, Anilkumar Gingade <[email protected]> wrote: > Hi Team, > > Wanted to get a closure on these topic. > > This may not impact Geode as its not yet released. But will impact the > existing GemFire installation (where next GemFire release is based on > Geode). > > *Rolling Upgrade *- Server upgrades without bringing down the cluster. > > Since we are changing the our membership layer (GEODE-77), the > RollingUpgrade from older GemFire versions will not be supported. We had > multiple conservation on this with GemFire PMs, Engineering team and agreed > on this. > > *Backward Compatibility* - Support for older versions of client to work > with newer versions of server cluster. > > We can still work towards to have backward compatibility supported with > membership changes (adds extra effort to do so); but with package name > changes we may not be able to support this. There was a discussion thread > started on this (below email); where possibility of keeping old package > names was discussed; but there was no final decision made on that thread. > > Do we need to support backward compatibility? > > Thanks, > -Anil. > > > Original Subject: Re: Repackaging src code to org.apache.geode > > On Thu, Jul 2, 2015 at 2:06 PM, Kirk Lund <[email protected]> wrote: > >> Yep, having 99% of the code in org.apache.geode pkgs with 1% in >> com.gemstone.gemfire pkgs just to facilitate rolling upgrades seems like >> something that would be reasonable to discuss on general@incubator. >> >> >> On Thu, Jul 2, 2015 at 12:35 PM, Bruce Schuchardt <[email protected] >> > >> wrote: >> >> > Hey, if we can do this then we should leave versions of exception >> classes >> > in com.gemstone.gemfire so we can send them to old GemFire clients! If >> we >> > do that and swizzle package names in DataSerializer maybe we'll be able >> to >> > support migration of GemFire clients to Geode. That would facilitate >> > faster adoption of Geode by users of the commercial product. >> > >> > >> > >> > >> > Le 7/2/2015 12:28 PM, Sean Busbey a écrit : >> > >> >> On Thu, Jul 2, 2015 at 1:25 PM, William Markito <[email protected]> >> >> wrote: >> >> >> >> My reading of that is it's specifically for incubation, which indeed >> is >> >>> not >> >>> required based on this thread >> >>> < >> >>> >> >>> >> https://www.mail-archive.com/[email protected]&q=subject:%22Package+renaming%5C%3F%22&o=newest&f=1 >> >>> . >> >>> >> >>> But for leaving incubation and becoming a TLP my understanding was >> that >> >>> it >> >>> is required. >> >>> >> >>> >> >>> Many projects leave code in packages that are not org.apache for >> >> backwards >> >> compatibility. >> >> >> >> Roman is correct, if you want to have things outside of org.apache you >> >> should bring up the matter on general@incubator. Including the >> reasoning >> >> for having things outside of org.apache and the long term plan (if any) >> >> for >> >> moving things will help avoid a longer set of questions. >> >> >> >> >> >> >> > >> > >
