+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 > >
