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.
> >>
> >>
> >>
> >
>

Reply via email to