> 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
