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 <jb...@pivotal.io> 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 <jb...@pivotal.io> 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 <mst...@pivotal.io> 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 <jb...@pivotal.io> 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 <mbr...@apache.org> 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)
