+1 > On 29 Mar 2021, at 15: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 >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
