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)
