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
