You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Anilkumar Gingade <ag...@pivotal.io> on 2015/09/02 23:38:04 UTC
Backward Compatibility and RollingUpgrade.
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 <kl...@pivotal.io> 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 <bs...@pivotal.io>
> 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 <wm...@pivotal.io>
> >> 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/search?l=dev@geode.incubator.apache.org&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.
> >>
> >>
> >>
> >
>
Re: [rtds-dev] Backward Compatibility and RollingUpgrade.
Posted by William Markito <wm...@pivotal.io>.
+1
We should definitely produce a table similar to that with
version/compatibility information.
On Wed, Sep 2, 2015 at 5:34 PM, Justin Erenkrantz <ju...@erenkrantz.com>
wrote:
> On Wed, Sep 2, 2015 at 6:12 PM, Darrel Schneider <ds...@pivotal.io>
> wrote:
> > 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?
>
> One of the very best things that I think we nailed in APR and
> Subversion was having a clearly-documented API and compatibility
> document.
>
> http://apr.apache.org/versioning.html
>
> http://subversion.apache.org/docs/community-guide/releasing.html#release-process
>
> As Geode has some downstream legacy users (due to Gemfire), while it
> could use this opportunity to change, it would be really good to be
> transparent about it as soon as possible - perhaps before the first
> incubation release is cut.
>
> It could be fine if Gemfire decides to maintain compatibility for its
> users in a specific set of libraries that aren't shipped with Geode
> (or even ALv2).
>
> Lots of different ways to go about it! -- justin
>
--
William Markito Oliveira
Enterprise Architect
-- For questions about Apache Geode, please write to
*dev@geode.incubator.apache.org
<de...@geode.incubator.apache.org>*
Re: [rtds-dev] Backward Compatibility and RollingUpgrade.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Sep 2, 2015 at 6:12 PM, Darrel Schneider <ds...@pivotal.io> wrote:
> 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?
One of the very best things that I think we nailed in APR and
Subversion was having a clearly-documented API and compatibility
document.
http://apr.apache.org/versioning.html
http://subversion.apache.org/docs/community-guide/releasing.html#release-process
As Geode has some downstream legacy users (due to Gemfire), while it
could use this opportunity to change, it would be really good to be
transparent about it as soon as possible - perhaps before the first
incubation release is cut.
It could be fine if Gemfire decides to maintain compatibility for its
users in a specific set of libraries that aren't shipped with Geode
(or even ALv2).
Lots of different ways to go about it! -- justin
Re: [rtds-dev] Backward Compatibility and RollingUpgrade.
Posted by Darrel Schneider <ds...@pivotal.io>.
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 <ag...@pivotal.io>
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 <kl...@pivotal.io> 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 <bschuchardt@pivotal.io
>> >
>> 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 <wm...@pivotal.io>
>> >> 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/search?l=dev@geode.incubator.apache.org&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.
>> >>
>> >>
>> >>
>> >
>>
>
>