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)
