Re: [DISCUSS] Support For LTS Version Of Geode
I think LTS implies a lot of things I’m not sure about yet. I suggest we keep the 1.9.x release line going to help “Spring Data for Apache Geode” on an as needed basis and see how it goes. Anthony > On Sep 30, 2019, at 6:32 PM, John Blum wrote: > > 1 more thing... > > I am also not saying all Apache Geode LTS versions (e.g. 1.9) need to > perfectly align with the SD Release Train for which the SD Release Train is > based (e.g. SD Moore/2.2 <-> 1.9), release by release, especially given we > have quite a few service/patch releases per SD Release Train (e.g. SD > Lovelace is already at SR10/2.1.10.RELEASE or 10 service/patch releases > beyond the 2.1 GA version, i.e. 2.1.0.RELEASE). Just that, enhancements, > important bug fixes, and CVEs (patches) are back ported to an LTS version > of Apache Geode from time to time up to, say, 1 year (or 3 or 4 patches). > > This may have the effect that Apache Geode users might not upgrade until a > new LTS version becomes available. However, for those that want to stay > ion the cutting edge, they are free to do so. It also allows the Apache > Geode product to take more risk between LTS versions and really stabilize > for an LTS version. > > To Owen's point, I am also wondering why it is so important that users > always pick up the latest bits? I think this is much more problematic to > do on the server-side, plus newer clients cannot talk to older servers, > so... > > And, of course, there is no reason why Apache Geode needs to do any of what > I am suggesting just for the Spring Data bits. But, it would make our > lives simpler overall, which is why I am advocating for it. > > Final $0.02, > > -j > > > > On Mon, Sep 30, 2019 at 6:13 PM John Blum wrote: > >> Well, release durations are subjective to begin with. What makes a 3 >> month cycle any better than a 6 month cycle or vice versa? >> >> For one, I think it is very project dependent. Rather, SD strives to >> achieve a predictable release cycle (i.e. fixed duration over X amount of >> scope, e.g. every 6 months, from M1 to final GA where we might have any >> number of Milestones and Release Candidates between M1 and final GA). >> Also, there is a commitment to our customers, so the 1 year cycle is not >> arbitrary. >> >> The entire SD Release Train also encompass 14 different modules >> (GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot >> more moving parts to coordinate with different intended feature sets per >> module (some of it aligning with SD Commons while other bits are very store >> specific) over the course of arriving at the final GA. >> >> Finally, I'd say that what is the point of having a patch version (i.e. in >> major.minor.patch) if the only intent to use is to fix CVEs. You could >> simply force users to the new minor version containing the fixes. >> >> However, I am very much in favor having patch releases, particularly for >> data products where upgrading is not a trivial task, and not simply a >> technical one, either. >> >> Again, $0.02, >> >> -John >> >> >> On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz wrote: >> >>> I agree. >>> >>> This is the most sensible way to achieve release alignment. >>> >>> >>> -- >>> Mike Stolz >>> Principal Engineer, Pivotal Cloud Cache >>> Mobile: +1-631-835-4771 >>> >>> On Mon, Sep 30, 2019, 8:09 PM John Blum wrote: >>> Put simply, from my perspective, I would like to see LTS versions of >>> Apache Geode align with the *Spring Data* (*Release Trains*) support for Apache Geode. For example: SDG Lovelace/2.1 is based on Apache Geode 1.6.x. SDG Moore/2.2 is based on Apache Geode 1.9.x. Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with >>> patch releases. The upcoming SD Neuman/2.3 (now in development given Moore has just >>> went GA (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) >>> before SD Neuman reaches RC1. SD has longer lifecycles between release trains (1 to 1.5 years per SD Release Train) than Apache Geode's support cycle, on a particular major.minor version (e.g. 1.9), which always puts us in a precarious position. $0.02 -John On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > Hi All, > > It has come up a few times in recent weeks about the possibility of an LTS > version of Geode. Is this something the community would be interested >>> in? > > There are advantages and disadvantages to supporting an LTS. Some > advantages may include: > - Stable release for downstream projects > - Include security and other maintenance related patches > > Disadvantages: > - Additional support for multiple distributions/versions > - Release management overhead > >
Re: [DISCUSS] Support For LTS Version Of Geode
1 more thing... I am also not saying all Apache Geode LTS versions (e.g. 1.9) need to perfectly align with the SD Release Train for which the SD Release Train is based (e.g. SD Moore/2.2 <-> 1.9), release by release, especially given we have quite a few service/patch releases per SD Release Train (e.g. SD Lovelace is already at SR10/2.1.10.RELEASE or 10 service/patch releases beyond the 2.1 GA version, i.e. 2.1.0.RELEASE). Just that, enhancements, important bug fixes, and CVEs (patches) are back ported to an LTS version of Apache Geode from time to time up to, say, 1 year (or 3 or 4 patches). This may have the effect that Apache Geode users might not upgrade until a new LTS version becomes available. However, for those that want to stay ion the cutting edge, they are free to do so. It also allows the Apache Geode product to take more risk between LTS versions and really stabilize for an LTS version. To Owen's point, I am also wondering why it is so important that users always pick up the latest bits? I think this is much more problematic to do on the server-side, plus newer clients cannot talk to older servers, so... And, of course, there is no reason why Apache Geode needs to do any of what I am suggesting just for the Spring Data bits. But, it would make our lives simpler overall, which is why I am advocating for it. Final $0.02, -j On Mon, Sep 30, 2019 at 6:13 PM John Blum wrote: > Well, release durations are subjective to begin with. What makes a 3 > month cycle any better than a 6 month cycle or vice versa? > > For one, I think it is very project dependent. Rather, SD strives to > achieve a predictable release cycle (i.e. fixed duration over X amount of > scope, e.g. every 6 months, from M1 to final GA where we might have any > number of Milestones and Release Candidates between M1 and final GA). > Also, there is a commitment to our customers, so the 1 year cycle is not > arbitrary. > > The entire SD Release Train also encompass 14 different modules > (GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot > more moving parts to coordinate with different intended feature sets per > module (some of it aligning with SD Commons while other bits are very store > specific) over the course of arriving at the final GA. > > Finally, I'd say that what is the point of having a patch version (i.e. in > major.minor.patch) if the only intent to use is to fix CVEs. You could > simply force users to the new minor version containing the fixes. > > However, I am very much in favor having patch releases, particularly for > data products where upgrading is not a trivial task, and not simply a > technical one, either. > > Again, $0.02, > > -John > > > On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz wrote: > >> I agree. >> >> This is the most sensible way to achieve release alignment. >> >> >> -- >> Mike Stolz >> Principal Engineer, Pivotal Cloud Cache >> Mobile: +1-631-835-4771 >> >> On Mon, Sep 30, 2019, 8:09 PM John Blum wrote: >> >> > Put simply, from my perspective, I would like to see LTS versions of >> Apache >> > Geode align with the *Spring Data* (*Release Trains*) support for Apache >> > Geode. >> > >> > For example: >> > >> > SDG Lovelace/2.1 is based on Apache Geode 1.6.x. >> > SDG Moore/2.2 is based on Apache Geode 1.9.x. >> > >> > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with >> patch >> > releases. >> > >> > The upcoming SD Neuman/2.3 (now in development given Moore has just >> went GA >> > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is >> > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) >> before >> > SD Neuman reaches RC1. >> > >> > SD has longer lifecycles between release trains (1 to 1.5 years per SD >> > Release Train) than Apache Geode's support cycle, on a particular >> > major.minor version (e.g. 1.9), which always puts us in a >> > precarious position. >> > >> > $0.02 >> > -John >> > >> > >> > >> > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: >> > >> > > Hi All, >> > > >> > > It has come up a few times in recent weeks about the possibility of an >> > LTS >> > > version of Geode. Is this something the community would be interested >> in? >> > > >> > > There are advantages and disadvantages to supporting an LTS. Some >> > > advantages may include: >> > > - Stable release for downstream projects >> > > - Include security and other maintenance related patches >> > > >> > > Disadvantages: >> > > - Additional support for multiple distributions/versions >> > > - Release management overhead >> > > >> > > Thoughts/Comments/Concerns? >> > > >> > > --Mark >> > > >> > >> > >> > -- >> > -John >> > john.blum10101 (skype) >> > >> > > > -- > -John > john.blum10101 (skype) > -- -John john.blum10101 (skype)
Re: [DISCUSS] Support For LTS Version Of Geode
Well, release durations are subjective to begin with. What makes a 3 month cycle any better than a 6 month cycle or vice versa? For one, I think it is very project dependent. Rather, SD strives to achieve a predictable release cycle (i.e. fixed duration over X amount of scope, e.g. every 6 months, from M1 to final GA where we might have any number of Milestones and Release Candidates between M1 and final GA). Also, there is a commitment to our customers, so the 1 year cycle is not arbitrary. The entire SD Release Train also encompass 14 different modules (GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot more moving parts to coordinate with different intended feature sets per module (some of it aligning with SD Commons while other bits are very store specific) over the course of arriving at the final GA. Finally, I'd say that what is the point of having a patch version (i.e. in major.minor.patch) if the only intent to use is to fix CVEs. You could simply force users to the new minor version containing the fixes. However, I am very much in favor having patch releases, particularly for data products where upgrading is not a trivial task, and not simply a technical one, either. Again, $0.02, -John On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz wrote: > I agree. > > This is the most sensible way to achieve release alignment. > > > -- > Mike Stolz > Principal Engineer, Pivotal Cloud Cache > Mobile: +1-631-835-4771 > > On Mon, Sep 30, 2019, 8:09 PM John Blum wrote: > > > Put simply, from my perspective, I would like to see LTS versions of > Apache > > Geode align with the *Spring Data* (*Release Trains*) support for Apache > > Geode. > > > > For example: > > > > SDG Lovelace/2.1 is based on Apache Geode 1.6.x. > > SDG Moore/2.2 is based on Apache Geode 1.9.x. > > > > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with > patch > > releases. > > > > The upcoming SD Neuman/2.3 (now in development given Moore has just went > GA > > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is > > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) > before > > SD Neuman reaches RC1. > > > > SD has longer lifecycles between release trains (1 to 1.5 years per SD > > Release Train) than Apache Geode's support cycle, on a particular > > major.minor version (e.g. 1.9), which always puts us in a > > precarious position. > > > > $0.02 > > -John > > > > > > > > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > > > > > Hi All, > > > > > > It has come up a few times in recent weeks about the possibility of an > > LTS > > > version of Geode. Is this something the community would be interested > in? > > > > > > There are advantages and disadvantages to supporting an LTS. Some > > > advantages may include: > > > - Stable release for downstream projects > > > - Include security and other maintenance related patches > > > > > > Disadvantages: > > > - Additional support for multiple distributions/versions > > > - Release management overhead > > > > > > Thoughts/Comments/Concerns? > > > > > > --Mark > > > > > > > > > -- > > -John > > john.blum10101 (skype) > > > -- -John john.blum10101 (skype)
Re: [DISCUSS] Support For LTS Version Of Geode
I agree. This is the most sensible way to achieve release alignment. -- Mike Stolz Principal Engineer, Pivotal Cloud Cache Mobile: +1-631-835-4771 On Mon, Sep 30, 2019, 8:09 PM John Blum wrote: > Put simply, from my perspective, I would like to see LTS versions of Apache > Geode align with the *Spring Data* (*Release Trains*) support for Apache > Geode. > > For example: > > SDG Lovelace/2.1 is based on Apache Geode 1.6.x. > SDG Moore/2.2 is based on Apache Geode 1.9.x. > > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with patch > releases. > > The upcoming SD Neuman/2.3 (now in development given Moore has just went GA > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) before > SD Neuman reaches RC1. > > SD has longer lifecycles between release trains (1 to 1.5 years per SD > Release Train) than Apache Geode's support cycle, on a particular > major.minor version (e.g. 1.9), which always puts us in a > precarious position. > > $0.02 > -John > > > > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > > > Hi All, > > > > It has come up a few times in recent weeks about the possibility of an > LTS > > version of Geode. Is this something the community would be interested in? > > > > There are advantages and disadvantages to supporting an LTS. Some > > advantages may include: > > - Stable release for downstream projects > > - Include security and other maintenance related patches > > > > Disadvantages: > > - Additional support for multiple distributions/versions > > - Release management overhead > > > > Thoughts/Comments/Concerns? > > > > --Mark > > > > > -- > -John > john.blum10101 (skype) >
Re: [DISCUSS] Support For LTS Version Of Geode
I am curious, what is the primary reason for such a long release cycle for Spring Data Geode? Also curious, what kinds of fixes is SDG expecting to “keep out” by locking in a particular minor release? Perhaps a good question for Geode is, why do we increment the minor version on every quarterly release, when most releases consist of mostly just bug fixes? If we were to create an LTS branch, would we end up back-porting virtually every commit? Is there any good reason why 1.10.0 couldn’t have been released as a 1.9.x? Just trying to understand what constitutes a patch release and what constitutes a minor, both from Geode’s perspective and from SDG’s perspective. The AEQ-pause feature requested for 1.9.2 casts doubt on the presumption that both Geode and SDG adhere strictly to semantic versioning... -Owen > On Sep 30, 2019, at 5:09 PM, John Blum wrote: > > Put simply, from my perspective, I would like to see LTS versions of Apache > Geode align with the *Spring Data* (*Release Trains*) support for Apache > Geode. > > For example: > > SDG Lovelace/2.1 is based on Apache Geode 1.6.x. > SDG Moore/2.2 is based on Apache Geode 1.9.x. > > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with patch > releases. > > The upcoming SD Neuman/2.3 (now in development given Moore has just went GA > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) before > SD Neuman reaches RC1. > > SD has longer lifecycles between release trains (1 to 1.5 years per SD > Release Train) than Apache Geode's support cycle, on a particular > major.minor version (e.g. 1.9), which always puts us in a > precarious position. > > $0.02 > -John > > > > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > >> Hi All, >> >> It has come up a few times in recent weeks about the possibility of an LTS >> version of Geode. Is this something the community would be interested in? >> >> There are advantages and disadvantages to supporting an LTS. Some >> advantages may include: >> - Stable release for downstream projects >> - Include security and other maintenance related patches >> >> Disadvantages: >> - Additional support for multiple distributions/versions >> - Release management overhead >> >> Thoughts/Comments/Concerns? >> >> --Mark >> > > > -- > -John > john.blum10101 (skype)
Re: [DISCUSS] Support For LTS Version Of Geode
Put simply, from my perspective, I would like to see LTS versions of Apache Geode align with the *Spring Data* (*Release Trains*) support for Apache Geode. For example: SDG Lovelace/2.1 is based on Apache Geode 1.6.x. SDG Moore/2.2 is based on Apache Geode 1.9.x. Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with patch releases. The upcoming SD Neuman/2.3 (now in development given Moore has just went GA (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) before SD Neuman reaches RC1. SD has longer lifecycles between release trains (1 to 1.5 years per SD Release Train) than Apache Geode's support cycle, on a particular major.minor version (e.g. 1.9), which always puts us in a precarious position. $0.02 -John On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl wrote: > Hi All, > > It has come up a few times in recent weeks about the possibility of an LTS > version of Geode. Is this something the community would be interested in? > > There are advantages and disadvantages to supporting an LTS. Some > advantages may include: > - Stable release for downstream projects > - Include security and other maintenance related patches > > Disadvantages: > - Additional support for multiple distributions/versions > - Release management overhead > > Thoughts/Comments/Concerns? > > --Mark > -- -John john.blum10101 (skype)
[DISCUSS] Support For LTS Version Of Geode
Hi All, It has come up a few times in recent weeks about the possibility of an LTS version of Geode. Is this something the community would be interested in? There are advantages and disadvantages to supporting an LTS. Some advantages may include: - Stable release for downstream projects - Include security and other maintenance related patches Disadvantages: - Additional support for multiple distributions/versions - Release management overhead Thoughts/Comments/Concerns? --Mark
