> I am planning to open some follow up discussions for those points in the coming weeks.
Awesome, thanks for coordinating this! > 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? Sounds good to me! > What do you think? +1 to Joey's addendum proposal to 3.0/3.11 end-of-support cycle. > I wanted to suggest an addendum that a review of 4.0/3.x support be done in (say) April 2022 in case of delays with 5.x [and beyond]. Thoughts? I think this is a valid point, but I don't think we need to prescribe this, since we can always re-discuss end-of-support dates if there is a delay. Perhaps we can add a short note to the support page that end-of-support dates may be revised if there are changes to the release schedule. Em seg., 29 de mar. de 2021 às 19:20, Erick Ramirez < erick.rami...@datastax.com> escreveu: > +1 excellent proposal. It makes it easier for the community to understand > and plan ahead. > > I wanted to suggest an addendum that a review of 4.0/3.x support be done in > (say) April 2022 in case of delays with 5.x [and beyond]. Thoughts? > > On Tue, 30 Mar 2021 at 01:41, Joseph Lynch <joe.e.ly...@gmail.com> wrote: > > > 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 > > > > >
