You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Joshua McKenzie <jm...@apache.org> on 2021/08/02 17:54:14 UTC
Re: [DISCUSS] Releases after 4.0
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....@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 <be...@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" <be...@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 <sa...@beobal.com>
> > wrote:
> >
> > > +1
> > >
> > > > On 29 Mar 2021, at 15:41, Joseph Lynch <jo...@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
> > > > <be...@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 <
> > pauloricardomg@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 <
> > > driftx@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 <
> > driftx@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 <
> > driftx@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
> > > >>>>>> <be...@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 <
> > mck@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-unsubscribe@cassandra.apache.org
> > > >>>>>>>> For additional commands, e-mail:
> > dev-help@cassandra.apache.org
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > >>>> For additional commands, e-mail:
> dev-help@cassandra.apache.org
> > > >>>>
> > > >>>>
> > > >>>
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: [DISCUSS] Releases after 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
Awesome - thanks Benjamin. What's the story with 2.2 EOL vs. critical only?
For what my .02 is worth, the stated "critical only to <month> 2022" seems
both sustainable for us as a community and better for our users given the
heavy lift that is updating to 3.0 or 3.11 for many users.d
On Tue, Aug 3, 2021 at 4:45 AM Mick Semb Wever <mc...@apache.org> wrote:
> >
> >
> > Wouldn't it make more sense to adjust the date to when the feature freeze
> > on trunk was lifted and 4.0 was branched?
> >
>
>
> Rationale to that is we _can_ lock to a date when the next release branch
> is created, and release off that branch.
> But we cannot determine that the next release (e.g. 4.1 GA) will actually
> pass a vote in any stated month, no matter how stable-trunk we are (and it
> would put us into feature freeze if we don't create such a release branch).
>
Re: [DISCUSS] Releases after 4.0
Posted by Mick Semb Wever <mc...@apache.org>.
>
>
> Wouldn't it make more sense to adjust the date to when the feature freeze
> on trunk was lifted and 4.0 was branched?
>
Rationale to that is we _can_ lock to a date when the next release branch
is created, and release off that branch.
But we cannot determine that the next release (e.g. 4.1 GA) will actually
pass a vote in any stated month, no matter how stable-trunk we are (and it
would put us into feature freeze if we don't create such a release branch).
Re: [DISCUSS] Releases after 4.0
Posted by Mick Semb Wever <mc...@apache.org>.
>
> 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.
>
Wouldn't it make more sense to adjust the date to when the feature freeze
on trunk was lifted and 4.0 was branched?
That was done on the 1st May.
(Also thinking that May is also better than July, regarding Summer
holidays.)
Re: [DISCUSS] Releases after 4.0
Posted by Benjamin Lerer <bl...@apache.org>.
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 <jm...@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.dimitrova@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 <be...@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" <be...@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 <sa...@beobal.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > > On 29 Mar 2021, at 15:41, Joseph Lynch <jo...@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
> > > > > <be...@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 <
> > > pauloricardomg@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 <
> > > > driftx@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 <
> > > driftx@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 <
> > > driftx@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
> > > > >>>>>> <be...@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 <
> > > mck@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-unsubscribe@cassandra.apache.org
> > > > >>>>>>>> For additional commands, e-mail:
> > > dev-help@cassandra.apache.org
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>
> > > > >>>>
> > > ---------------------------------------------------------------------
> > > > >>>> To unsubscribe, e-mail:
> dev-unsubscribe@cassandra.apache.org
> > > > >>>> For additional commands, e-mail:
> > dev-help@cassandra.apache.org
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>
Re: [DISCUSS] Releases after 4.0
Posted by Scott Carey <sc...@gmail.com>.
Just my random thoughts as an outsider while trying to look at this thread
months after the fact. I could have missed some details along the way and
might not quite understand the final proposal.
On this topic in general, it seems a bit odd to me to have support / fixes
for a release defined primarily as an amount of time after the release date
given that future releases can't be guaranteed to hit a specific month. It
also causes exceptions to the rule for 3.0 and 3.11. If instead, the
support interval was primarily defined relative to the date of future
releases, the result would be a (near) constant number of supported
releases, regardless of the pace of the releases. A minimum support
interval would probably be needed in case the pace quickens to faster than
one a year, however.
For example, if major version N is released today, it could mean that
existing releases all 'roll down' a tier 2 months after that: N-3 has 2
months left of critical/high severity bug fixes before retirement,, N-2
becomes high severity only in 3 months, etc. The 2 month buffer in this
example allows for a last round of important fixes to occur right after a
major release, when it is likely that resources that were focused on the
major release free up to do any final work / review on fixes for older or
retiring branches..
In effect for 4.0, this would mean something like
4.0 full support until two months after 6.0 is released, or 2 years,
whichever is longer.
4.0 critical fixes until two months after 7.0 is released, or 3 years,
wichever is longer.
this automatically takes care of the long time delay for 3.0 and 3.11
without any special exceptions for them. And in the future, if there was
an extra-long release for some reasonit would not cause a reduction in the
number of actively supported versions, nor affect the 'cadence' of
major-release -> final fixups for old branches. It also allows for
occasional shorter releases without any increase in the total branches
supported if the average of the last few is still about one year. For
example, maybe major release X takes 14 months, then major release X+1
takes 10 months.
On Mon, Aug 2, 2021 at 10:55 AM Joshua McKenzie <jm...@apache.org>
wrote:
> 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.dimitrova@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 <be...@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" <be...@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 <sa...@beobal.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > > On 29 Mar 2021, at 15:41, Joseph Lynch <jo...@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
> > > > > <be...@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 <
> > > pauloricardomg@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 <
> > > > driftx@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 <
> > > driftx@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 <
> > > driftx@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
> > > > >>>>>> <be...@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 <
> > > mck@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-unsubscribe@cassandra.apache.org
> > > > >>>>>>>> For additional commands, e-mail:
> > > dev-help@cassandra.apache.org
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>
> > > > >>>>
> > > ---------------------------------------------------------------------
> > > > >>>> To unsubscribe, e-mail:
> dev-unsubscribe@cassandra.apache.org
> > > > >>>> For additional commands, e-mail:
> > dev-help@cassandra.apache.org
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>