I updated the website when we thought that we would reach GA in April. After that updating the website was complicated so I decided to wait for the actual GA. So to answer to your question Josh: Yes we need to update the dates to July. I also promised to put the Roadmap on the website and I will do it as soon as I can. If somebody else wants to do it, it is fine for me too.
Le lun. 2 août 2021 à 19:55, Joshua McKenzie <jmcken...@apache.org> a écrit : > Where did we land on this? Joey's statement above: > > > * 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) > > > Doesn't look like it matches what we have on the site: > https://cassandra.apache.org/_/download.html > > Apache Cassandra 2.2 > > Released on 2020-11-04, and supported until 4.1 release (April 2022) with > > critical fixes only. > > > Also - do we need to revise our dates from April 2022 to July 2022 to > reflect when GA hit? > > > > On Thu, Apr 1, 2021 at 10:06 AM Ekaterina Dimitrova <e.dimitr...@gmail.com > > > wrote: > > > +1 on my end about the Roadmap page and to start looking in the future > > again :-) I am also optimistic about the assumption of having 4.0 out in > > April :-) Exciting times > > > > On Thu, 1 Apr 2021 at 9:37, Benedict Elliott Smith <bened...@apache.org> > > wrote: > > > > > > it would make sense to put that information on a *Roadmap* page > > > > > > That makes sense to me, and I'm looking forward to agreeing a roadmap. > I > > > think it will be nice for the project to start properly looking to the > > > future again. > > > > > > On 01/04/2021, 14:06, "Benjamin Lerer" <benjamin.le...@datastax.com> > > > wrote: > > > > > > Thanks everybody. > > > > > > I opened CASSANDRA-16556 > > > <https://issues.apache.org/jira/browse/CASSANDRA-16556> to update > > the > > > end > > > of support dates for the different versions. I assumed that we will > > > manage > > > to release 4.0-GA in April (otherwise I will re-update them ;-) ) > > > > > > Concerning the release cadence, it seems that we do not have a > proper > > > place > > > to put that information on our website. In an offline discussion > Mick > > > raised the point that it would make sense to put that information > on > > a > > > *Roadmap > > > *page. That makes sense to me. I will trigger the roadmap > discussion > > > next > > > week and once we agree on some roadmap, I propose to create a new > > page > > > for > > > it where I will include the information on the release cadence. > > > > > > I am fully open to another proposal. > > > > > > > > > On Tue, Mar 30, 2021 at 11:24 AM Sam Tunnicliffe <s...@beobal.com> > > > wrote: > > > > > > > +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 > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > >
