I am slightly concerned about removing support for critical bug fixes in 3.0 on a short time-frame (<1 year). I know of at least a few major installations, including ours, who are just now able to finish upgrades to 3.0 in production due to the number of correctness and performance bugs introduced in that release which have only been debugged and fixed in the past ~2 years.
I like the idea of the 3-year support cycles, but I think since 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade to, we should reset the clock somewhat. What about the following assuming an April 2021 4.0 cut: 4.0: Fully supported until April 2023 and high severity bugs until April 2024 (2 year full, 1 year bugfix) 3.11: Fully supported until April 2022 and high severity bugs until April 2023 (1 year full, 1 year bugfix). 3.0: Supported for high severity correctness/performance bugs until April 2022 (1 year bugfix) 2.2+2.1: EOL immediately. Then going forward we could have this nice pattern when we cut the yearly release: Y(n-0): Support for 3 years from now (2 full, 1 bugfix) Y(n-1): Fully supported for 1 more year and supported for high severity correctness/perf bugs 1 year after that (1 full, 1 bugfix) Y(n-2): Supported for high severity correctness/bugs for 1 more year (1 bugfix) What do you think? -Joey On Mon, Mar 29, 2021 at 9:39 AM Benjamin Lerer <benjamin.le...@datastax.com> wrote: > > Thanks to everybody and sorry for not finalizing that email thread sooner. > > For the release cadence the agreement is:* one release every year + > periodic trunc snapshot* > For the number of releases being supported the agreement is 3. *Every > incoming release should be supported for 3 years.* > > We did not reach a clear agreement on several points : > * The naming of versions: semver versus another approach and the name of > snapshot versions > * How long will we support 3.11. Taking into account that it has been > released 4 years ago does it make sense to support it for the next 3 years? > > I am planning to open some follow up discussions for those points in the > coming weeks. > > When there is an agreement we should document the changes on the webpage > > and also highlight it as part of the 4.0 release material as it's an > > important change to the release cycle and LTS support. > > > > It is a valid point. Do you mind if I update the documentation when we have > clarified the version names and that we have a more precise idea of when > 4.0 GA will be released? That will allow us to make a clear message on when > to expect the next supported version. > > On Mon, Feb 8, 2021 at 10:05 PM Paulo Motta <pauloricard...@gmail.com> > wrote: > > > +1 to the yearly release cadence + periodic trunk snapshots + support to 3 > > previous release branches.. I think this will give some nice predictability > > to the project. > > > > When there is an agreement we should document the changes on the webpage > > and also highlight it as part of the 4.0 release material as it's an > > important change to the release cycle and LTS support. > > > > Em sex., 5 de fev. de 2021 às 18:08, Brandon Williams <dri...@gmail.com> > > escreveu: > > > > > Perhaps on my third try... keep three branches total, including 3.11: > > > 3.11, 4, next. Support for 3.11 begins ending after next+1, is what > > > I'm trying to convey. > > > > > > On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams <dri...@gmail.com> > > wrote: > > > > > > > > Err, to be clear: keep 3.11 until we have 3 other branches. > > > > > > > > On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams <dri...@gmail.com> > > > wrote: > > > > > > > > > > I'm +1 on 3 branches, and thus ~3 years of support. So in the > > > > > transition, would we aim to keep 3.11 until after 4.0 and a successor > > > > > are released? > > > > > > > > > > On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer > > > > > <benjamin.le...@datastax.com> wrote: > > > > > > > > > > > > > > > > > > > > Are we also trying to reach a consensus here that a release > > branch > > > should > > > > > > > be supported for ~3 years (i.e. that we are aiming to limit > > > ourselves to 3 > > > > > > > release branches plus trunk)? > > > > > > > > > > > > > > > > > > 3 release branches make sense to me +1 > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever <m...@apache.org> > > > wrote: > > > > > > > > > > > > > > > > > > > > > I believe that there is an appetite for the bleeding edge > > > snapshots where > > > > > > > > we do not guarantee stability and that the semver discussion is > > > not > > > > > > > > finished yet but I would like us to let those discussions go > > for > > > some > > > > > > > > follow up threads. > > > > > > > > My goal with this thread was to reach an agreement on a release > > > cadence > > > > > > > for > > > > > > > > the version we will officially support after 4.0. > > > > > > > > > > > > > > > > My impression is that most people agree with *one release every > > > year* so > > > > > > > I > > > > > > > > would like to propose it as our future release cadence. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +1 to branching off one release branch a year. > > > > > > > > > > > > > > Are we also trying to reach a consensus here that a release > > branch > > > should > > > > > > > be supported for ~3 years (i.e. that we are aiming to limit > > > ourselves to 3 > > > > > > > release branches plus trunk)? > > > > > > > > > > > > > > +1 to flexible dates. > > > > > > > > > > > > > > +1 to non-GA non-branched releases along the way. > > > > > > > > > > > > > > > > > > > > > Jeremiah, I have nothing to add to your post. I think you did a > > > fantastic > > > > > > > job of combining how semver would work in combination Benedict's > > > focus on > > > > > > > cadence and reducing the community burden. It also helped > > > highlight the > > > > > > > different discussions to be had, that should be had separately. > > > Thanks > > > > > > > Benjamin for bringing it back to what was your original questions > > > (sorry > > > > > > > for the derail): > > > > > > > > > > > > > > > 1) What release cadence do we want to use for major/minor > > > versions? > > > > > > > > 2) How do we plan to ensure the quality of the releases? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
