Re: [DISCUSS] Releases after 4.0

[Scott Carey]

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 
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  >
> 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 
> > 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" 
> > > wrote:
> > >
> > > Thanks everybody.
> > >
> > > I opened 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 

Re: [DISCUSS] Releases after 4.0

[Joshua McKenzie]

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

[Mick Semb Wever]

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

[Mick Semb Wever]

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

[Benjamin Lerer]

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  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  >
> 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 
> > 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" 
> > > wrote:
> > >
> > > Thanks everybody.
> > >
> > > I opened 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 
> > > wrote:
> > >
> > > > +1
> > > >
> > > > > On 29 Mar 2021, at 15:41, Joseph Lynch 
> > > 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): 

Re: [DISCUSS] Releases after 4.0

[Joshua McKenzie]

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 
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 
> 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" 
> > wrote:
> >
> > Thanks everybody.
> >
> > I opened 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 
> > wrote:
> >
> > > +1
> > >
> > > > On 29 Mar 2021, at 15:41, Joseph Lynch 
> > 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
> > > >  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 

Re: [DISCUSS] Releases after 4.0

[Ekaterina Dimitrova]

+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 
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" 
> wrote:
>
> Thanks everybody.
>
> I opened 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 
> wrote:
>
> > +1
> >
> > > On 29 Mar 2021, at 15:41, Joseph Lynch 
> 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
> > >  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
> > 

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

> 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"  wrote:

Thanks everybody.

I opened 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  wrote:

> +1
>
> > On 29 Mar 2021, at 15:41, Joseph Lynch  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
> >  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 
> >> 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:
>  

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

Thanks everybody.

I opened 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  wrote:

> +1
>
> > On 29 Mar 2021, at 15:41, Joseph Lynch  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
> >  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 
> >> 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 
> >>> 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 
>  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
> >>  wrote:
> >>>
> 
>  Are we also trying to reach a consensus here that a 

Re: [DISCUSS] Releases after 4.0

[Sam Tunnicliffe]

+1

> On 29 Mar 2021, at 15:41, Joseph Lynch  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
>  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 
>> 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 
>>> 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 
>>> 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 
 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
>>  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 
 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 

Re: [DISCUSS] Releases after 4.0

[Berenguer Blasi]

+1

On 30/3/21 3:43, David Capwell wrote:
> +1
>
>> On Mar 29, 2021, at 2:48 PM, Benedict Elliott Smith  
>> wrote:
>>
>> +1
>>
>> On 29/03/2021, 21:16, "Ben Bromhead"  wrote:
>>
>>+1 good sensible suggestion.
>>
>>On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova 
>> 
>>wrote:
>>
>>> I also like the latest suggestion, +1, thank you
>>>
>>> On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:
>>>
 +1

 On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
 wrote:

> +1 that deprecation schedule seems reasonable and a good thing to move
 to.
>> On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
 wrote:
>> The proposal sounds good to me too.
>>
>>> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> écrit :
 On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <
>>> joe.e.ly...@gmail.com>
 wrote:
 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.
>>> I agree, the length of time to release 4.0 and the initialization
>>> of a
>>> new release cycle requires some special consideration for current
>>> releases.
>>>
 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)
>>>
>>> This sounds excellent to me, +1.
>>>
>>>
>>> -
>>> 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
>
>
>>
>>-- 
>>
>>Ben Bromhead
>>
>>Instaclustr | www.instaclustr.com | @instaclustr
>> | +64 27 383 8975
>>
>>
>>
>> -
>> 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

Re: [DISCUSS] Releases after 4.0

[David Capwell]

+1

> On Mar 29, 2021, at 2:48 PM, Benedict Elliott Smith  
> wrote:
> 
> +1
> 
> On 29/03/2021, 21:16, "Ben Bromhead"  wrote:
> 
>+1 good sensible suggestion.
> 
>On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova 
>wrote:
> 
>> I also like the latest suggestion, +1, thank you
>> 
>> On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:
>> 
>>> +1
>>> 
>>> On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
>>> wrote:
>>> 
 +1 that deprecation schedule seems reasonable and a good thing to move
>>> to.
 
> On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
>>> wrote:
> 
> The proposal sounds good to me too.
> 
>> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
 écrit :
>> 
>>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <
>> joe.e.ly...@gmail.com>
>>> wrote:
>>> 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.
>> 
>> I agree, the length of time to release 4.0 and the initialization
>> of a
>> new release cycle requires some special consideration for current
>> releases.
>> 
>>> 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)
>> 
>> This sounds excellent to me, +1.
>> 
>> 
>> -
>> 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
 
 
>>> 
>> 
> 
> 
>-- 
> 
>Ben Bromhead
> 
>Instaclustr | www.instaclustr.com | @instaclustr
> | +64 27 383 8975
> 
> 
> 
> -
> 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

Re: [DISCUSS] Releases after 4.0

[Paulo Motta]

> I am planning to open some follow up discussions for those points in the
coming weeks.

Awesome, thanks for coordinating this!

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

Sounds good to me!

>  What do you think?

+1 to Joey's addendum proposal to 3.0/3.11 end-of-support cycle.

> I wanted to suggest an addendum that a review of 4.0/3.x support be done
in
(say) April 2022 in case of delays with 5.x [and beyond]. Thoughts?

I think this is a valid point, but I don't think we need to prescribe this,
since we can always re-discuss end-of-support dates if there is a delay.
Perhaps we can add a short note to the support page that end-of-support
dates may be revised if there are changes to the release schedule.

Em seg., 29 de mar. de 2021 às 19:20, Erick Ramirez <
erick.rami...@datastax.com> escreveu:

> +1 excellent proposal. It makes it easier for the community to understand
> and plan ahead.
>
> I wanted to suggest an addendum that a review of 4.0/3.x support be done in
> (say) April 2022 in case of delays with 5.x [and beyond]. Thoughts?
>
> On Tue, 30 Mar 2021 at 01:41, Joseph Lynch  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
> >  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 
> > > 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 
> > > > wrote:
> > > > > >
> > > > > > 

Re: [DISCUSS] Releases after 4.0

[Erick Ramirez]

+1 excellent proposal. It makes it easier for the community to understand
and plan ahead.

I wanted to suggest an addendum that a review of 4.0/3.x support be done in
(say) April 2022 in case of delays with 5.x [and beyond]. Thoughts?

On Tue, 30 Mar 2021 at 01:41, Joseph Lynch  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
>  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 
> > 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 
> > > 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 
> > > > 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
> > > > > >  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

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

+1

On 29/03/2021, 21:16, "Ben Bromhead"  wrote:

+1 good sensible suggestion.

On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova 
wrote:

> I also like the latest suggestion, +1, thank you
>
> On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:
>
> > +1
> >
> > On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
> > wrote:
> >
> > > +1 that deprecation schedule seems reasonable and a good thing to move
> > to.
> > >
> > > > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
> > wrote:
> > > >
> > > > The proposal sounds good to me too.
> > > >
> > > >> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> > > écrit :
> > > >>
> > > >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <
> joe.e.ly...@gmail.com>
> > > >>> wrote:
> > > >>> 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.
> > > >>
> > > >> I agree, the length of time to release 4.0 and the initialization
> of a
> > > >> new release cycle requires some special consideration for current
> > > >> releases.
> > > >>
> > > >>> 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)
> > > >>
> > > >> This sounds excellent to me, +1.
> > > >>
> > > >>
> -
> > > >> 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
> > >
> > >
> >
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Ben Bromhead]

+1 good sensible suggestion.

On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova 
wrote:

> I also like the latest suggestion, +1, thank you
>
> On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:
>
> > +1
> >
> > On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
> > wrote:
> >
> > > +1 that deprecation schedule seems reasonable and a good thing to move
> > to.
> > >
> > > > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
> > wrote:
> > > >
> > > > The proposal sounds good to me too.
> > > >
> > > >> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> > > écrit :
> > > >>
> > > >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <
> joe.e.ly...@gmail.com>
> > > >>> wrote:
> > > >>> 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.
> > > >>
> > > >> I agree, the length of time to release 4.0 and the initialization
> of a
> > > >> new release cycle requires some special consideration for current
> > > >> releases.
> > > >>
> > > >>> 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)
> > > >>
> > > >> This sounds excellent to me, +1.
> > > >>
> > > >>
> -
> > > >> 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
> > >
> > >
> >
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975

Re: [DISCUSS] Releases after 4.0

[Ekaterina Dimitrova]

I also like the latest suggestion, +1, thank you

On Mon, 29 Mar 2021 at 14:16, Yifan Cai  wrote:

> +1
>
> On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
> wrote:
>
> > +1 that deprecation schedule seems reasonable and a good thing to move
> to.
> >
> > > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer 
> wrote:
> > >
> > > The proposal sounds good to me too.
> > >
> > >> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> > écrit :
> > >>
> > >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch 
> > >>> wrote:
> > >>> 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.
> > >>
> > >> I agree, the length of time to release 4.0 and the initialization of a
> > >> new release cycle requires some special consideration for current
> > >> releases.
> > >>
> > >>> 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)
> > >>
> > >> This sounds excellent to me, +1.
> > >>
> > >> -
> > >> 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
> >
> >
>

Re: [DISCUSS] Releases after 4.0

[Yifan Cai]

+1

On Mon, Mar 29, 2021 at 8:42 AM J. D. Jordan 
wrote:

> +1 that deprecation schedule seems reasonable and a good thing to move to.
>
> > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer  wrote:
> >
> > The proposal sounds good to me too.
> >
> >> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a
> écrit :
> >>
> >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch 
> >>> wrote:
> >>> 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.
> >>
> >> I agree, the length of time to release 4.0 and the initialization of a
> >> new release cycle requires some special consideration for current
> >> releases.
> >>
> >>> 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)
> >>
> >> This sounds excellent to me, +1.
> >>
> >> -
> >> 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
>
>

Re: [DISCUSS] Releases after 4.0

[J. D. Jordan]

+1 that deprecation schedule seems reasonable and a good thing to move to.

> On Mar 29, 2021, at 10:23 AM, Benjamin Lerer  wrote:
> 
> The proposal sounds good to me too.
> 
>> Le lun. 29 mars 2021 à 16:48, Brandon Williams  a écrit :
>> 
>>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch 
>>> wrote:
>>> 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.
>> 
>> I agree, the length of time to release 4.0 and the initialization of a
>> new release cycle requires some special consideration for current
>> releases.
>> 
>>> 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)
>> 
>> This sounds excellent to me, +1.
>> 
>> -
>> 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

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

The proposal sounds good to me too.

Le lun. 29 mars 2021 à 16:48, Brandon Williams  a écrit :

> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch 
> wrote:
> > 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.
>
> I agree, the length of time to release 4.0 and the initialization of a
> new release cycle requires some special consideration for current
> releases.
>
> > 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)
>
> This sounds excellent to me, +1.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Releases after 4.0

[Brandon Williams]

On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch  wrote:
> 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.

I agree, the length of time to release 4.0 and the initialization of a
new release cycle requires some special consideration for current
releases.

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

This sounds excellent to me, +1.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Joseph Lynch]

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

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

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

Re: [DISCUSS] Releases after 4.0

[Paulo Motta]

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

Re: [DISCUSS] Releases after 4.0

[Brandon Williams]

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

Re: [DISCUSS] Releases after 4.0

[Brandon Williams]

Err, to be clear: keep 3.11 until we have 3 other branches.

On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams  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
>  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  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

Re: [DISCUSS] Releases after 4.0

[Brandon Williams]

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

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

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

Re: [DISCUSS] Releases after 4.0

[Michael Semb Wever]

> 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

Re: [DISCUSS] Releases after 4.0

[Brandon Williams]

+1 to both yearly release and periodic snapshots.

As far as timing goes, I would like to avoid picking a specific date
for release, and instead choose something like "the first Wednesday of
May" or something.

On Fri, Feb 5, 2021 at 10:20 AM Sam Tunnicliffe  wrote:
>
> +1 to both the yearly cadence and the periodic publishing of bleeding edge 
> snapshots.
>
> > On 5 Feb 2021, at 16:14, Benedict Elliott Smith  wrote:
> >
> > +1
> >
> > +1 also to mixing this with an experiment on regular "releasable" (without 
> > API stability) snapshots from trunk.
> >
> > On 05/02/2021, 16:07, "Joshua McKenzie"  wrote:
> >
> >+1 from me on the yearly cadence fwiw. The space this project is in 
> > (infra
> >software) is directly at odds for many users' preferred release cadence
> >(preferably never or bugfix only for existing / stable projects) compared
> >to how fast the NoSQL / database ecosystem is evolving; once a year seems
> >to strike a reasonable balance between the various constituents.
> >
> >On Fri, Feb 5, 2021 at 9:58 AM Benjamin Lerer 
> > 
> >wrote:
> >
> >> Thanks for your responses.
> >>
> >> I had some offline discussions with different persons to gather more
> >> feedback on the current discussion.
> >> The people I talked to appeared to be in favor of one supported release
> >> every year as Benedict initially suggested.
> >> The advantages mentioned were:
> >> * it is long enough to allow us to have a significant amount of work done
> >> * if some work slip to the next release it will only be delayed for one
> >> year
> >> * it does not create too much burden in term of release maintenance
> >> * it provides some certainty to the community
> >>
> >> 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.
> >>
> >> Your feedback is welcome.
> >>
> >>
> >> On Thu, Jan 28, 2021 at 6:45 PM Jeremiah D Jordan <
> >> jeremiah.jor...@gmail.com>
> >> wrote:
> >>
> >>> I think we are confusing things between minor vs patch.  Can we talk
> >> about
> >>> branch names?
> >>>
> >>> I think we can agree on the following statements?
> >>>
> >>> Releases made from stable maintenance branches,
> >>> cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit
> >>> features being added to them and should be mostly bug fix only.
> >>>
> >>> New features will be developed in trunk.
> >>>
> >>> Now I think the thing under discussion here is “how often will we cut new
> >>> maintenance branches from trunk” and also “how long will we maintain
> >> those
> >>> branches"
> >>>
> >>> I would definitely like to see the project able to release binaries from
> >>> trunk more often then once a year.  As long as we keep our quality goals
> >> in
> >>> line post 4.0 GA I think this is possible.
> >>>
>  I'd like to see us have three branches: life support (critical fixes),
> >>> stable (fixes), and development. Minors don't fit very well into that
> >> IMO.
> >>>
> >>> If we want to go with semver ideas, then minors fit perfectly well.
> >>> Server doesn’t meant you make patch releases for every version you have
> >>> ever released, it is just a way of versioning the releases so people can
> >>> understand what the upgrade semantics are for that release.  If you
> >> dropped
> >>> support for some existing thing, you need to bump the major version, if
> >> you
> >>> added something new you bump the minor version, if you only fixed bugs
> >> with
> >>> no user visible changes you bump the patch version.
> >>>
>  I suppose in practice all this wouldn't be too different to tick-tock,
> >>> just with a better state of QA, a higher bar to merge and (perhaps) no
> >>> fixed release cadence. This realisation makes me less keen on it, for
> >> some
> >>> reason.
> >>>
> >>> I was thinking something along these lines might be useful as well.
> >>>
> >>> I could see a process where we cut new maintenance branches every X time,
> >>> ~1 year?, 6 months?, we would fix bugs and make patch releases from those
> >>> maintenance branches.
> >>> We would also cut releases from the development branch (trunk) more
> >>> often.  The version number in trunk would be updated based on what had
> >>> changed since the last release made from trunk.  If we dropped support
> >> for
> >>> something since the last release, bump major.  If we added new features
> >>> (most likely thing), bump minor.
> >>>
> >>> So when we release 4.0 we cut the cassandra-4.0 maintenance branch.  We
> >>> make future 4.0.1 4.0.2 4.0.3 releases from this branch.
> >>>

Re: [DISCUSS] Releases after 4.0

[Sam Tunnicliffe]

+1 to both the yearly cadence and the periodic publishing of bleeding edge 
snapshots.

> On 5 Feb 2021, at 16:14, Benedict Elliott Smith  wrote:
> 
> +1
> 
> +1 also to mixing this with an experiment on regular "releasable" (without 
> API stability) snapshots from trunk.
> 
> On 05/02/2021, 16:07, "Joshua McKenzie"  wrote:
> 
>+1 from me on the yearly cadence fwiw. The space this project is in (infra
>software) is directly at odds for many users' preferred release cadence
>(preferably never or bugfix only for existing / stable projects) compared
>to how fast the NoSQL / database ecosystem is evolving; once a year seems
>to strike a reasonable balance between the various constituents.
> 
>On Fri, Feb 5, 2021 at 9:58 AM Benjamin Lerer 
>wrote:
> 
>> Thanks for your responses.
>> 
>> I had some offline discussions with different persons to gather more
>> feedback on the current discussion.
>> The people I talked to appeared to be in favor of one supported release
>> every year as Benedict initially suggested.
>> The advantages mentioned were:
>> * it is long enough to allow us to have a significant amount of work done
>> * if some work slip to the next release it will only be delayed for one
>> year
>> * it does not create too much burden in term of release maintenance
>> * it provides some certainty to the community
>> 
>> 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.
>> 
>> Your feedback is welcome.
>> 
>> 
>> On Thu, Jan 28, 2021 at 6:45 PM Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com>
>> wrote:
>> 
>>> I think we are confusing things between minor vs patch.  Can we talk
>> about
>>> branch names?
>>> 
>>> I think we can agree on the following statements?
>>> 
>>> Releases made from stable maintenance branches,
>>> cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit
>>> features being added to them and should be mostly bug fix only.
>>> 
>>> New features will be developed in trunk.
>>> 
>>> Now I think the thing under discussion here is “how often will we cut new
>>> maintenance branches from trunk” and also “how long will we maintain
>> those
>>> branches"
>>> 
>>> I would definitely like to see the project able to release binaries from
>>> trunk more often then once a year.  As long as we keep our quality goals
>> in
>>> line post 4.0 GA I think this is possible.
>>> 
 I'd like to see us have three branches: life support (critical fixes),
>>> stable (fixes), and development. Minors don't fit very well into that
>> IMO.
>>> 
>>> If we want to go with semver ideas, then minors fit perfectly well.
>>> Server doesn’t meant you make patch releases for every version you have
>>> ever released, it is just a way of versioning the releases so people can
>>> understand what the upgrade semantics are for that release.  If you
>> dropped
>>> support for some existing thing, you need to bump the major version, if
>> you
>>> added something new you bump the minor version, if you only fixed bugs
>> with
>>> no user visible changes you bump the patch version.
>>> 
 I suppose in practice all this wouldn't be too different to tick-tock,
>>> just with a better state of QA, a higher bar to merge and (perhaps) no
>>> fixed release cadence. This realisation makes me less keen on it, for
>> some
>>> reason.
>>> 
>>> I was thinking something along these lines might be useful as well.
>>> 
>>> I could see a process where we cut new maintenance branches every X time,
>>> ~1 year?, 6 months?, we would fix bugs and make patch releases from those
>>> maintenance branches.
>>> We would also cut releases from the development branch (trunk) more
>>> often.  The version number in trunk would be updated based on what had
>>> changed since the last release made from trunk.  If we dropped support
>> for
>>> something since the last release, bump major.  If we added new features
>>> (most likely thing), bump minor.
>>> 
>>> So when we release 4.0 we cut the cassandra-4.0 maintenance branch.  We
>>> make future 4.0.1 4.0.2 4.0.3 releases from this branch.
>>> 
>>> Trunk continues development, some new features are added there.  After a
>>> few months we release 4.1.0 from trunk, we do not cut a cassandra-4.1
>>> branch.  Development continues along on trunk, some new features get in
>> so
>>> we bump the version in the branch to 4.2.0.  A few months go by we
>> release
>>> 4.2.0 from trunk.  Some bug fixes go into trunk with no new features, the
>>> version on the branch bumps to 4.2.1, we decide to make a release from
>>> 

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

+1

+1 also to mixing this with an experiment on regular "releasable" (without API 
stability) snapshots from trunk.

On 05/02/2021, 16:07, "Joshua McKenzie"  wrote:

+1 from me on the yearly cadence fwiw. The space this project is in (infra
software) is directly at odds for many users' preferred release cadence
(preferably never or bugfix only for existing / stable projects) compared
to how fast the NoSQL / database ecosystem is evolving; once a year seems
to strike a reasonable balance between the various constituents.

On Fri, Feb 5, 2021 at 9:58 AM Benjamin Lerer 
wrote:

> Thanks for your responses.
>
> I had some offline discussions with different persons to gather more
> feedback on the current discussion.
> The people I talked to appeared to be in favor of one supported release
> every year as Benedict initially suggested.
> The advantages mentioned were:
> * it is long enough to allow us to have a significant amount of work done
> * if some work slip to the next release it will only be delayed for one
> year
> * it does not create too much burden in term of release maintenance
> * it provides some certainty to the community
>
> 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.
>
> Your feedback is welcome.
>
>
> On Thu, Jan 28, 2021 at 6:45 PM Jeremiah D Jordan <
> jeremiah.jor...@gmail.com>
> wrote:
>
> > I think we are confusing things between minor vs patch.  Can we talk
> about
> > branch names?
> >
> > I think we can agree on the following statements?
> >
> > Releases made from stable maintenance branches,
> > cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit
> > features being added to them and should be mostly bug fix only.
> >
> > New features will be developed in trunk.
> >
> > Now I think the thing under discussion here is “how often will we cut 
new
> > maintenance branches from trunk” and also “how long will we maintain
> those
> > branches"
> >
> > I would definitely like to see the project able to release binaries from
> > trunk more often then once a year.  As long as we keep our quality goals
> in
> > line post 4.0 GA I think this is possible.
> >
> > > I'd like to see us have three branches: life support (critical fixes),
> > stable (fixes), and development. Minors don't fit very well into that
> IMO.
> >
> > If we want to go with semver ideas, then minors fit perfectly well.
> > Server doesn’t meant you make patch releases for every version you have
> > ever released, it is just a way of versioning the releases so people can
> > understand what the upgrade semantics are for that release.  If you
> dropped
> > support for some existing thing, you need to bump the major version, if
> you
> > added something new you bump the minor version, if you only fixed bugs
> with
> > no user visible changes you bump the patch version.
> >
> > > I suppose in practice all this wouldn't be too different to tick-tock,
> > just with a better state of QA, a higher bar to merge and (perhaps) no
> > fixed release cadence. This realisation makes me less keen on it, for
> some
> > reason.
> >
> > I was thinking something along these lines might be useful as well.
> >
> > I could see a process where we cut new maintenance branches every X 
time,
> > ~1 year?, 6 months?, we would fix bugs and make patch releases from 
those
> > maintenance branches.
> > We would also cut releases from the development branch (trunk) more
> > often.  The version number in trunk would be updated based on what had
> > changed since the last release made from trunk.  If we dropped support
> for
> > something since the last release, bump major.  If we added new features
> > (most likely thing), bump minor.
> >
> > So when we release 4.0 we cut the cassandra-4.0 maintenance branch.  We
> > make future 4.0.1 4.0.2 4.0.3 releases from this branch.
> >
> > Trunk continues development, some new features are added there.  After a
> > few months we release 4.1.0 from trunk, we do not cut a cassandra-4.1
> > branch.  Development continues along on trunk, some new features get in
> so
> > we bump the version in the branch to 4.2.0.  A few months go by we
> release
> > 

Re: [DISCUSS] Releases after 4.0

[Joshua McKenzie]

+1 from me on the yearly cadence fwiw. The space this project is in (infra
software) is directly at odds for many users' preferred release cadence
(preferably never or bugfix only for existing / stable projects) compared
to how fast the NoSQL / database ecosystem is evolving; once a year seems
to strike a reasonable balance between the various constituents.

On Fri, Feb 5, 2021 at 9:58 AM Benjamin Lerer 
wrote:

> Thanks for your responses.
>
> I had some offline discussions with different persons to gather more
> feedback on the current discussion.
> The people I talked to appeared to be in favor of one supported release
> every year as Benedict initially suggested.
> The advantages mentioned were:
> * it is long enough to allow us to have a significant amount of work done
> * if some work slip to the next release it will only be delayed for one
> year
> * it does not create too much burden in term of release maintenance
> * it provides some certainty to the community
>
> 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.
>
> Your feedback is welcome.
>
>
> On Thu, Jan 28, 2021 at 6:45 PM Jeremiah D Jordan <
> jeremiah.jor...@gmail.com>
> wrote:
>
> > I think we are confusing things between minor vs patch.  Can we talk
> about
> > branch names?
> >
> > I think we can agree on the following statements?
> >
> > Releases made from stable maintenance branches,
> > cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit
> > features being added to them and should be mostly bug fix only.
> >
> > New features will be developed in trunk.
> >
> > Now I think the thing under discussion here is “how often will we cut new
> > maintenance branches from trunk” and also “how long will we maintain
> those
> > branches"
> >
> > I would definitely like to see the project able to release binaries from
> > trunk more often then once a year.  As long as we keep our quality goals
> in
> > line post 4.0 GA I think this is possible.
> >
> > > I'd like to see us have three branches: life support (critical fixes),
> > stable (fixes), and development. Minors don't fit very well into that
> IMO.
> >
> > If we want to go with semver ideas, then minors fit perfectly well.
> > Server doesn’t meant you make patch releases for every version you have
> > ever released, it is just a way of versioning the releases so people can
> > understand what the upgrade semantics are for that release.  If you
> dropped
> > support for some existing thing, you need to bump the major version, if
> you
> > added something new you bump the minor version, if you only fixed bugs
> with
> > no user visible changes you bump the patch version.
> >
> > > I suppose in practice all this wouldn't be too different to tick-tock,
> > just with a better state of QA, a higher bar to merge and (perhaps) no
> > fixed release cadence. This realisation makes me less keen on it, for
> some
> > reason.
> >
> > I was thinking something along these lines might be useful as well.
> >
> > I could see a process where we cut new maintenance branches every X time,
> > ~1 year?, 6 months?, we would fix bugs and make patch releases from those
> > maintenance branches.
> > We would also cut releases from the development branch (trunk) more
> > often.  The version number in trunk would be updated based on what had
> > changed since the last release made from trunk.  If we dropped support
> for
> > something since the last release, bump major.  If we added new features
> > (most likely thing), bump minor.
> >
> > So when we release 4.0 we cut the cassandra-4.0 maintenance branch.  We
> > make future 4.0.1 4.0.2 4.0.3 releases from this branch.
> >
> > Trunk continues development, some new features are added there.  After a
> > few months we release 4.1.0 from trunk, we do not cut a cassandra-4.1
> > branch.  Development continues along on trunk, some new features get in
> so
> > we bump the version in the branch to 4.2.0.  A few months go by we
> release
> > 4.2.0 from trunk.  Some bug fixes go into trunk with no new features, the
> > version on the branch bumps to 4.2.1, we decide to make a release from
> > trunk, and only fixes have gone into trunk since the last release, so we
> > release 4.2.1 from trunk.
> >
> > We continue on this way releasing 4.3.0, 4.4.0, 4.4.1 …. We decide it is
> > time for a new maintenance branch to be cut.  So with the release of
> 4.5.0
> > we also cut the cassandra-4.5 branch.  This branch will get patch
> releases
> > made from it 4.5.1 4.5.2 4.5.3.
> >
> > Trunk continues on as 4.6.0, 4.7.0, 

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

Thanks for your responses.

I had some offline discussions with different persons to gather more
feedback on the current discussion.
The people I talked to appeared to be in favor of one supported release
every year as Benedict initially suggested.
The advantages mentioned were:
* it is long enough to allow us to have a significant amount of work done
* if some work slip to the next release it will only be delayed for one year
* it does not create too much burden in term of release maintenance
* it provides some certainty to the community

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.

Your feedback is welcome.


On Thu, Jan 28, 2021 at 6:45 PM Jeremiah D Jordan 
wrote:

> I think we are confusing things between minor vs patch.  Can we talk about
> branch names?
>
> I think we can agree on the following statements?
>
> Releases made from stable maintenance branches,
> cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit
> features being added to them and should be mostly bug fix only.
>
> New features will be developed in trunk.
>
> Now I think the thing under discussion here is “how often will we cut new
> maintenance branches from trunk” and also “how long will we maintain those
> branches"
>
> I would definitely like to see the project able to release binaries from
> trunk more often then once a year.  As long as we keep our quality goals in
> line post 4.0 GA I think this is possible.
>
> > I'd like to see us have three branches: life support (critical fixes),
> stable (fixes), and development. Minors don't fit very well into that IMO.
>
> If we want to go with semver ideas, then minors fit perfectly well.
> Server doesn’t meant you make patch releases for every version you have
> ever released, it is just a way of versioning the releases so people can
> understand what the upgrade semantics are for that release.  If you dropped
> support for some existing thing, you need to bump the major version, if you
> added something new you bump the minor version, if you only fixed bugs with
> no user visible changes you bump the patch version.
>
> > I suppose in practice all this wouldn't be too different to tick-tock,
> just with a better state of QA, a higher bar to merge and (perhaps) no
> fixed release cadence. This realisation makes me less keen on it, for some
> reason.
>
> I was thinking something along these lines might be useful as well.
>
> I could see a process where we cut new maintenance branches every X time,
> ~1 year?, 6 months?, we would fix bugs and make patch releases from those
> maintenance branches.
> We would also cut releases from the development branch (trunk) more
> often.  The version number in trunk would be updated based on what had
> changed since the last release made from trunk.  If we dropped support for
> something since the last release, bump major.  If we added new features
> (most likely thing), bump minor.
>
> So when we release 4.0 we cut the cassandra-4.0 maintenance branch.  We
> make future 4.0.1 4.0.2 4.0.3 releases from this branch.
>
> Trunk continues development, some new features are added there.  After a
> few months we release 4.1.0 from trunk, we do not cut a cassandra-4.1
> branch.  Development continues along on trunk, some new features get in so
> we bump the version in the branch to 4.2.0.  A few months go by we release
> 4.2.0 from trunk.  Some bug fixes go into trunk with no new features, the
> version on the branch bumps to 4.2.1, we decide to make a release from
> trunk, and only fixes have gone into trunk since the last release, so we
> release 4.2.1 from trunk.
>
> We continue on this way releasing 4.3.0, 4.4.0, 4.4.1 …. We decide it is
> time for a new maintenance branch to be cut.  So with the release of 4.5.0
> we also cut the cassandra-4.5 branch.  This branch will get patch releases
> made from it 4.5.1 4.5.2 4.5.3.
>
> Trunk continues on as 4.6.0, 4.7.0, 4.8.0 …. At some point the project
> decides it wants to drop support for some deprecated feature, trunk gets
> bumped to 5.0.0. More releases happen from trunk 5.0.0, 5.1.0, 5.2.0, 5.2.1
> development on trunk continues on.  Time for a new maintenance branch with
> 5.3.0 so cassandra-5.3 gets cut...
>
> This does kind of look like what we tried for tick/tock, but it is not the
> same.  If we wanted to name this something, I would call it something like
> "releasable trunk+periodic maintenance branching”.  This is what many
> projects that release from trunk look like.
>
> -Jeremiah
>
>
> > On Jan 28, 2021, at 10:31 AM, Benedict Elliott Smith <

Re: [DISCUSS] Releases after 4.0

[Jeremiah D Jordan]

I think we are confusing things between minor vs patch.  Can we talk about 
branch names?

I think we can agree on the following statements?

Releases made from stable maintenance branches, 
cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit features 
being added to them and should be mostly bug fix only.

New features will be developed in trunk.

Now I think the thing under discussion here is “how often will we cut new 
maintenance branches from trunk” and also “how long will we maintain those 
branches"

I would definitely like to see the project able to release binaries from trunk 
more often then once a year.  As long as we keep our quality goals in line post 
4.0 GA I think this is possible.

> I'd like to see us have three branches: life support (critical fixes), stable 
> (fixes), and development. Minors don't fit very well into that IMO.

If we want to go with semver ideas, then minors fit perfectly well.  Server 
doesn’t meant you make patch releases for every version you have ever released, 
it is just a way of versioning the releases so people can understand what the 
upgrade semantics are for that release.  If you dropped support for some 
existing thing, you need to bump the major version, if you added something new 
you bump the minor version, if you only fixed bugs with no user visible changes 
you bump the patch version.

> I suppose in practice all this wouldn't be too different to tick-tock, just 
> with a better state of QA, a higher bar to merge and (perhaps) no fixed 
> release cadence. This realisation makes me less keen on it, for some reason.

I was thinking something along these lines might be useful as well.

I could see a process where we cut new maintenance branches every X time, ~1 
year?, 6 months?, we would fix bugs and make patch releases from those 
maintenance branches.
We would also cut releases from the development branch (trunk) more often.  The 
version number in trunk would be updated based on what had changed since the 
last release made from trunk.  If we dropped support for something since the 
last release, bump major.  If we added new features (most likely thing), bump 
minor.

So when we release 4.0 we cut the cassandra-4.0 maintenance branch.  We make 
future 4.0.1 4.0.2 4.0.3 releases from this branch.

Trunk continues development, some new features are added there.  After a few 
months we release 4.1.0 from trunk, we do not cut a cassandra-4.1 branch.  
Development continues along on trunk, some new features get in so we bump the 
version in the branch to 4.2.0.  A few months go by we release 4.2.0 from 
trunk.  Some bug fixes go into trunk with no new features, the version on the 
branch bumps to 4.2.1, we decide to make a release from trunk, and only fixes 
have gone into trunk since the last release, so we release 4.2.1 from trunk.

We continue on this way releasing 4.3.0, 4.4.0, 4.4.1 …. We decide it is time 
for a new maintenance branch to be cut.  So with the release of 4.5.0 we also 
cut the cassandra-4.5 branch.  This branch will get patch releases made from it 
4.5.1 4.5.2 4.5.3.

Trunk continues on as 4.6.0, 4.7.0, 4.8.0 …. At some point the project decides 
it wants to drop support for some deprecated feature, trunk gets bumped to 
5.0.0. More releases happen from trunk 5.0.0, 5.1.0, 5.2.0, 5.2.1 development 
on trunk continues on.  Time for a new maintenance branch with 5.3.0 so 
cassandra-5.3 gets cut...

This does kind of look like what we tried for tick/tock, but it is not the 
same.  If we wanted to name this something, I would call it something like 
"releasable trunk+periodic maintenance branching”.  This is what many projects 
that release from trunk look like.

-Jeremiah


> On Jan 28, 2021, at 10:31 AM, Benedict Elliott Smith  
> wrote:
> 
> But, as discussed, we previously agreed limit features in a minor version, as 
> per the release lifecycle (and I continue to endorse this decision)
> 
> On 28/01/2021, 16:04, "Mick Semb Wever"  wrote:
> 
>> if there's no such features, or anything breaking compatibility
>> 
>> What do you envisage being delivered in such a release, besides bug
>> fixes?  Do we have the capacity as a project for releases dedicated to
>> whatever falls between those two gaps?
>> 
> 
> 
>All releases that don't break any compatibilities as our documented
>guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).  Even
>new features can be introduced without compatibility breakages (and should
>be as often as possible).
> 
>Honouring semver does not imply more releases, to the contrary it is just
>that a number of those existing releases will be minor instead of major.
>That is, it is an opportunity cost to not recognise minor releases.
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

Re: [DISCUSS] Releases after 4.0

[Jonathan Ellis]

Sorry, I got my threads crossed!

On Thu, Jan 28, 2021 at 10:47 AM Jonathan Ellis  wrote:

> cqlsh isn't a new feature.
>
> On Thu, Jan 28, 2021 at 10:32 AM Benedict Elliott Smith <
> bened...@apache.org> wrote:
>
>> But, as discussed, we previously agreed limit features in a minor
>> version, as per the release lifecycle (and I continue to endorse this
>> decision)
>>
>> On 28/01/2021, 16:04, "Mick Semb Wever"  wrote:
>>
>> > if there's no such features, or anything breaking compatibility
>> >
>> > What do you envisage being delivered in such a release, besides bug
>> > fixes?  Do we have the capacity as a project for releases dedicated
>> to
>> > whatever falls between those two gaps?
>> >
>>
>>
>> All releases that don't break any compatibilities as our documented
>> guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).
>> Even
>> new features can be introduced without compatibility breakages (and
>> should
>> be as often as possible).
>>
>> Honouring semver does not imply more releases, to the contrary it is
>> just
>> that a number of those existing releases will be minor instead of
>> major.
>> That is, it is an opportunity cost to not recognise minor releases.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>


-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: [DISCUSS] Releases after 4.0

[Jonathan Ellis]

cqlsh isn't a new feature.

On Thu, Jan 28, 2021 at 10:32 AM Benedict Elliott Smith 
wrote:

> But, as discussed, we previously agreed limit features in a minor version,
> as per the release lifecycle (and I continue to endorse this decision)
>
> On 28/01/2021, 16:04, "Mick Semb Wever"  wrote:
>
> > if there's no such features, or anything breaking compatibility
> >
> > What do you envisage being delivered in such a release, besides bug
> > fixes?  Do we have the capacity as a project for releases dedicated
> to
> > whatever falls between those two gaps?
> >
>
>
> All releases that don't break any compatibilities as our documented
> guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).
> Even
> new features can be introduced without compatibility breakages (and
> should
> be as often as possible).
>
> Honouring semver does not imply more releases, to the contrary it is
> just
> that a number of those existing releases will be minor instead of
> major.
> That is, it is an opportunity cost to not recognise minor releases.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

But, as discussed, we previously agreed limit features in a minor version, as 
per the release lifecycle (and I continue to endorse this decision)

On 28/01/2021, 16:04, "Mick Semb Wever"  wrote:

> if there's no such features, or anything breaking compatibility
>
> What do you envisage being delivered in such a release, besides bug
> fixes?  Do we have the capacity as a project for releases dedicated to
> whatever falls between those two gaps?
>


All releases that don't break any compatibilities as our documented
guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).  Even
new features can be introduced without compatibility breakages (and should
be as often as possible).

Honouring semver does not imply more releases, to the contrary it is just
that a number of those existing releases will be minor instead of major.
That is, it is an opportunity cost to not recognise minor releases.



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Mick Semb Wever]

> if there's no such features, or anything breaking compatibility
>
> What do you envisage being delivered in such a release, besides bug
> fixes?  Do we have the capacity as a project for releases dedicated to
> whatever falls between those two gaps?
>


All releases that don't break any compatibilities as our documented
guidelines dictate (wrt. upgrades, api, cql, native protocol, etc).  Even
new features can be introduced without compatibility breakages (and should
be as often as possible).

Honouring semver does not imply more releases, to the contrary it is just
that a number of those existing releases will be minor instead of major.
That is, it is an opportunity cost to not recognise minor releases.

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

> if there's no such features, or anything breaking compatibility

What do you envisage being delivered in such a release, besides bug fixes?  Do 
we have the capacity as a project for releases dedicated to whatever falls 
between those two gaps?

I'd like to see us have three branches: life support (critical fixes), stable 
(fixes), and development. Minors don't fit very well into that IMO.

> I am a bit scared of a continuous delivery approach for a database 
> due to the lack of guarantee on the APIs and protocols as you mentioned

Well, this could be resolved by marking features as unstable, then 
experimental, as we have begun doing. So that API stability is tied to features 
more tightly than releases.  I'm actually warming to this configuration, but I 
think we're all circling ideas in a similar vicinity and I suspect none of us 
are tightly wed to the specifics.

> we should allow ourselves to cut a release sooner. 

The only issue here is that we then create an extra maintenance overhead, as we 
have more releases to manage.  This is one advantage of the CD approach - we 
nominate a release much less frequently for long term support, at which point 
we rollover to a new major (presumably also only deprecating across such a 
boundary).

I suppose in practice all this wouldn't be too different to tick-tock, just 
with a better state of QA, a higher bar to merge and (perhaps) no fixed release 
cadence. This realisation makes me less keen on it, for some reason.




On 28/01/2021, 14:23, "Mick Semb Wever"  wrote:

We have had a very problematic history with release versioning, such that
> our users probably think the numbers are meaningless.
>


Completely agree with this. But it feels that we're throwing the baby out
with the bath water…

I do think we can do semver with just a minimal amount of dev guidelines in
place, to great benefit to users (and for ourselves).



> However, in the new release lifecycle document (and in follow-up
> discussions around qualifying releases) we curtail _features_ once a
> release is GA, and also stipulate that a new major version is associated
> with a release.
>


The following aspects remain open questions for me…
 - if there's no such features, or anything breaking compatibility, isn't
there benefit in releasing a minor,
 - can we better indicate to users the upgrade path (and how we simplify
which upgrade paths we have to support),
 - the practice of deprecating an API one release and then removing it the
following,
 - we have CQL, Native Protocol, SSTable versioning, can they tie in to our
semver (especially their majors, which are also about compatibility)

I would have thought we have enough here to provide a set of guidelines to
the dev community about when a release is either a major or minor. The
missing piece here is how do we apply a branching strategy. I would suggest
the same branching strategy that we would do under your suggestion of
, so that the decision about a release being a major or a
minor can be lazy made. It may be in practice that this starts off with
every release being a major, as you have suggested, but we would keep the
minor numbers and semver there to use when we see fit. If our practices
improve, with the dev guidelines in place, we may see that releases become
mostly minors.

And I see this increases relevance if we introduce more SPIs into the
codebase and have a bigger dev ecosystem around us, e.g. storage engine,
compaction, indexes, thin-coordinators… Already today we know we have
consumers of our maven artifacts, and dependency hell is a big part of
semver's value, ref: https://semver.org/



> Why make a release at a fixed time each year?
> > Stable-trunk is more popularly associated with Continuously Delivered
> (CD) codebases
>
> We need to pick some points in time to provide stability/patch support
> for, and an annual cadence provides some certainty to the community.
>


What we can do depends on how much time the community has to contribute.
That is a changing and responsive thing. We can aim for an objective, and
improve/streamline processes and guidelines.

So, my suggestion is to…
 - keep semver,
 - we decide whether a release is major or minor when we agree to cut a
release, and
 - that decision is primarily based on documented dev guidelines.



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Releases after 4.0

[Mick Semb Wever]

We have had a very problematic history with release versioning, such that
> our users probably think the numbers are meaningless.
>


Completely agree with this. But it feels that we're throwing the baby out
with the bath water…

I do think we can do semver with just a minimal amount of dev guidelines in
place, to great benefit to users (and for ourselves).



> However, in the new release lifecycle document (and in follow-up
> discussions around qualifying releases) we curtail _features_ once a
> release is GA, and also stipulate that a new major version is associated
> with a release.
>


The following aspects remain open questions for me…
 - if there's no such features, or anything breaking compatibility, isn't
there benefit in releasing a minor,
 - can we better indicate to users the upgrade path (and how we simplify
which upgrade paths we have to support),
 - the practice of deprecating an API one release and then removing it the
following,
 - we have CQL, Native Protocol, SSTable versioning, can they tie in to our
semver (especially their majors, which are also about compatibility)

I would have thought we have enough here to provide a set of guidelines to
the dev community about when a release is either a major or minor. The
missing piece here is how do we apply a branching strategy. I would suggest
the same branching strategy that we would do under your suggestion of
, so that the decision about a release being a major or a
minor can be lazy made. It may be in practice that this starts off with
every release being a major, as you have suggested, but we would keep the
minor numbers and semver there to use when we see fit. If our practices
improve, with the dev guidelines in place, we may see that releases become
mostly minors.

And I see this increases relevance if we introduce more SPIs into the
codebase and have a bigger dev ecosystem around us, e.g. storage engine,
compaction, indexes, thin-coordinators… Already today we know we have
consumers of our maven artifacts, and dependency hell is a big part of
semver's value, ref: https://semver.org/



> Why make a release at a fixed time each year?
> > Stable-trunk is more popularly associated with Continuously Delivered
> (CD) codebases
>
> We need to pick some points in time to provide stability/patch support
> for, and an annual cadence provides some certainty to the community.
>


What we can do depends on how much time the community has to contribute.
That is a changing and responsive thing. We can aim for an objective, and
improve/streamline processes and guidelines.

So, my suggestion is to…
 - keep semver,
 - we decide whether a release is major or minor when we agree to cut a
release, and
 - that decision is primarily based on documented dev guidelines.

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

 I am a bit scared of a continuous delivery approach for a database due to
the lack of guarantee on the APIs and protocols as you mentioned. On the
other hand an annual major release cadence seems a bit too inflexible for
me.
It makes sense to me to ensure that we release at least one major version
per year, nevertheless I believe that if we see that a significant amount
of work has been released (for example 3 or 4 CEPs) we should allow
ourselves to cut a release sooner. Making an official release would force
us to go beyond our normal testing ensuring that we did not introduce new
defects that our tests could have missed. Interaction between features is
often a weak spot from the testing point of view.

What do you think?


On Thu, Jan 28, 2021 at 1:25 PM Benedict Elliott Smith 
wrote:

> We have had a very problematic history with release versioning, such that
> our users probably think the numbers are meaningless.
>
> However, in the new release lifecycle document (and in follow-up
> discussions around qualifying releases) we curtail _features_ once a
> release is GA, and also stipulate that a new major version is associated
> with a release.
>
> This happens to accord with my preference, namely that we eliminate the
> concept of a minor release in semver terms. We have feature releases and
> patch releases. i.e., 4.0's first bug fix release is 4.1, and in a year we
> ship 5.0.  There has been support voiced for this in a couple of forums
> (including on this list back in 2019), but it was perhaps never fully
> discussed/settled.
>
> > Why make a release at a fixed time each year?
> > Stable-trunk is more popularly associated with Continuously Delivered
> (CD) codebases
>
> We need to pick some points in time to provide stability/patch support
> for, and an annual cadence provides some certainty to the community.
> Perhaps it wouldn't make sense if we aim for true continuous delivery of
> trunk. However, there is value in flexibility to experiment/revisit
> decisions before committing to APIs and feature behaviours long term. By
> providing continuous delivery of builds that do not guarantee API stability
> for new features/APIs, users that are able to accept some small risk in
> this regard (e.g. during development, or where they do not intend to use
> the new features) may still benefit from access to high quality releases
> quickly, and the project gets more rapid feedback.
>
> Perhaps we can have a flexible approach though, wherein we have continuous
> delivery of release candidates, and on arbitrary timelines cut releases
> that create API-stability points, and periodically nominate such releases
> to receive 3+ years of support.
>
>
>
> On 28/01/2021, 11:42, "Mick Semb Wever"  wrote:
>
> > I'd like to pair this with stricter merge criteria, so that we
> maintain a
> ~shippable trunk, [snip]. We might have to get happy with reverting
> commits
> that break things.
>
>
> Yes and yes! The work we have done, started on, and undercovered in
> the 4.0
> Quality Testing Epics should continue.
>
> Our CI systems have also improved. Folk are using both circleci and
> ci-cassandra, and i think the combination brings an advantage.  Though
> there's still a lot to do. CircleCI doesn't cover everything, and
> with ci-cassandra there are a few things still to do. For example:
> arm64,
> jmh, jacoco, dtest-large-novnode, and putting dtest-upgrade into the
> pipeline. Jira tickets exist for these. Another issue we have is
> reliably
> identifying flaky tests and test history. All test results and logs
> are now
> getting stored in nightlies.a.o, so the data is there to achieve it,
> but
> searching it remains overly raw.
>
> If such efforts continue, as they have, we should definitely be able to
> avoid repeating the feature freeze requirement.
>
>
> > My preference is for a simple annual major release cadence, with
> minors
> as necessary. This is simple for the user community and developer
> community: support = x versions = x years.
>
> This raises a number of questions for me.
>
> Why make a release at a fixed time each year?
> The idea of one major release a year contradicts in practice any
> efforts
> towards a stable-trunk. Stable-trunk is more popularly associated with
> Continuously Delivered (CD) codebases. Yearly releases are not quite
> that,
> and I can't see a stricter merge criteria compensating enough. I have
> put
> effort into the release process, and encouraged the community to have
> more
> active release managers, so that when we need a release we can get
> one. We
> should be looking into cutting patch releases as often as possible.
>
> For how many years shall we support major versions?
> Currently we maintain three release branches, plus one limited to
> security
> issues, and the oldest has been supported for 5 years. I think 5 years
> is
> too long for the 

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

We have had a very problematic history with release versioning, such that our 
users probably think the numbers are meaningless.

However, in the new release lifecycle document (and in follow-up discussions 
around qualifying releases) we curtail _features_ once a release is GA, and 
also stipulate that a new major version is associated with a release.

This happens to accord with my preference, namely that we eliminate the concept 
of a minor release in semver terms. We have feature releases and patch 
releases. i.e., 4.0's first bug fix release is 4.1, and in a year we ship 5.0.  
There has been support voiced for this in a couple of forums (including on this 
list back in 2019), but it was perhaps never fully discussed/settled.

> Why make a release at a fixed time each year?
> Stable-trunk is more popularly associated with Continuously Delivered (CD) 
> codebases

We need to pick some points in time to provide stability/patch support for, and 
an annual cadence provides some certainty to the community.  Perhaps it 
wouldn't make sense if we aim for true continuous delivery of trunk. However, 
there is value in flexibility to experiment/revisit decisions before committing 
to APIs and feature behaviours long term. By providing continuous delivery of 
builds that do not guarantee API stability for new features/APIs, users that 
are able to accept some small risk in this regard (e.g. during development, or 
where they do not intend to use the new features) may still benefit from access 
to high quality releases quickly, and the project gets more rapid feedback.

Perhaps we can have a flexible approach though, wherein we have continuous 
delivery of release candidates, and on arbitrary timelines cut releases that 
create API-stability points, and periodically nominate such releases to receive 
3+ years of support. 



On 28/01/2021, 11:42, "Mick Semb Wever"  wrote:

> I'd like to pair this with stricter merge criteria, so that we maintain a
~shippable trunk, [snip]. We might have to get happy with reverting commits
that break things.


Yes and yes! The work we have done, started on, and undercovered in the 4.0
Quality Testing Epics should continue.

Our CI systems have also improved. Folk are using both circleci and
ci-cassandra, and i think the combination brings an advantage.  Though
there's still a lot to do. CircleCI doesn't cover everything, and
with ci-cassandra there are a few things still to do. For example: arm64,
jmh, jacoco, dtest-large-novnode, and putting dtest-upgrade into the
pipeline. Jira tickets exist for these. Another issue we have is reliably
identifying flaky tests and test history. All test results and logs are now
getting stored in nightlies.a.o, so the data is there to achieve it, but
searching it remains overly raw.

If such efforts continue, as they have, we should definitely be able to
avoid repeating the feature freeze requirement.


> My preference is for a simple annual major release cadence, with minors
as necessary. This is simple for the user community and developer
community: support = x versions = x years.

This raises a number of questions for me.

Why make a release at a fixed time each year?
The idea of one major release a year contradicts in practice any efforts
towards a stable-trunk. Stable-trunk is more popularly associated with
Continuously Delivered (CD) codebases. Yearly releases are not quite that,
and I can't see a stricter merge criteria compensating enough. I have put
effort into the release process, and encouraged the community to have more
active release managers, so that when we need a release we can get one. We
should be looking into cutting patch releases as often as possible.

For how many years shall we support major versions?
Currently we maintain three release branches, plus one limited to security
issues, and the oldest has been supported for 5 years. I think 5 years is
too long for the current community and would suggest bringing it down to 3
years. The project is maturing, and along with efforts towards a
stable-trunk, I would expect upgrades to be getting easier. Asking users to
upgrade at least once every three years shouldn't be a big deal for an OSS
project.


> I understood us to have agreed to drop semver, because our major/minor
history has been a meaningless distinction…


I am not sure that I understand that point, is there reference to this
agreement?
Not releasing minor versions doesn't mean we drop semver, we still have the
three numbers there in our versions. In your first reply you wrote that we
would do "minors as necessary", what were your thoughts on what a minor was
there? Was it just a relabelling of patch versions?

Now that we have our Release Lifecycle guidelines defined, which included
discussions on compatibility issues, isn't it a good 

Re: [DISCUSS] Releases after 4.0

[Mick Semb Wever]

> I'd like to pair this with stricter merge criteria, so that we maintain a
~shippable trunk, [snip]. We might have to get happy with reverting commits
that break things.


Yes and yes! The work we have done, started on, and undercovered in the 4.0
Quality Testing Epics should continue.

Our CI systems have also improved. Folk are using both circleci and
ci-cassandra, and i think the combination brings an advantage.  Though
there's still a lot to do. CircleCI doesn't cover everything, and
with ci-cassandra there are a few things still to do. For example: arm64,
jmh, jacoco, dtest-large-novnode, and putting dtest-upgrade into the
pipeline. Jira tickets exist for these. Another issue we have is reliably
identifying flaky tests and test history. All test results and logs are now
getting stored in nightlies.a.o, so the data is there to achieve it, but
searching it remains overly raw.

If such efforts continue, as they have, we should definitely be able to
avoid repeating the feature freeze requirement.


> My preference is for a simple annual major release cadence, with minors
as necessary. This is simple for the user community and developer
community: support = x versions = x years.

This raises a number of questions for me.

Why make a release at a fixed time each year?
The idea of one major release a year contradicts in practice any efforts
towards a stable-trunk. Stable-trunk is more popularly associated with
Continuously Delivered (CD) codebases. Yearly releases are not quite that,
and I can't see a stricter merge criteria compensating enough. I have put
effort into the release process, and encouraged the community to have more
active release managers, so that when we need a release we can get one. We
should be looking into cutting patch releases as often as possible.

For how many years shall we support major versions?
Currently we maintain three release branches, plus one limited to security
issues, and the oldest has been supported for 5 years. I think 5 years is
too long for the current community and would suggest bringing it down to 3
years. The project is maturing, and along with efforts towards a
stable-trunk, I would expect upgrades to be getting easier. Asking users to
upgrade at least once every three years shouldn't be a big deal for an OSS
project.


> I understood us to have agreed to drop semver, because our major/minor
history has been a meaningless distinction…


I am not sure that I understand that point, is there reference to this
agreement?
Not releasing minor versions doesn't mean we drop semver, we still have the
three numbers there in our versions. In your first reply you wrote that we
would do "minors as necessary", what were your thoughts on what a minor was
there? Was it just a relabelling of patch versions?

Now that we have our Release Lifecycle guidelines defined, which included
discussions on compatibility issues, isn't it a good time to also define
what "incompatible API changes" is for us?

If we define "incompatible API changes" then each release should be simple
enough to know whether it is going to be a major or minor. This also comes
back to our support window, if we have a three year support window and only
yearly major versions, does that not mean we are then asking users to
perform three upgrades every three years?

I am pretty sure I would favour defining what "incompatible API changes"
means for us, and aim for only one major every three years but let the PMC
make exceptions as we go along when we see fit, knowing the cost the
exception comes with.

We are already getting better at identifying what incompatibilities are, as a
requirement we have put on ourselves with the Release Lifecycle guidelines.
  And I assume that pushing for a stable-trunk effectively implies some
semver like strategy, allowing us to re-use our identification of
incompatibilities. In short, if we are making ourselves better at
identifying incompatibilities (because of the Release Lifecycle), why would
we not re-use that to benefit the user?

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

I understood us to have agreed to drop semver, because our major/minor history 
has been a meaningless distinction, and instead to go major/patch (or 
major/minor - with minor for patches), depending how you want to slice it.

But there have been a lot of discussions over the past year or so, so I may be 
misremembering.

On 27/01/2021, 13:25, "Benjamin Lerer"  wrote:

>
> My preference is for a simple annual major release cadence, with minors as
> necessary.
>

I do not think that I fully understand your proposal. How do you define a
major and a minor release?
My understanding of a major release was a version that broke some of the
compatibilities. By consequence, once a breaking change has been introduced
it will not be possible to release a minor and we will have to wait for a
major release. In a similar way if no breaking change has been introduced,
does it make sense to release a major?




On Wed, Jan 27, 2021 at 11:21 AM Benedict Elliott Smith 

wrote:

> Perhaps we could also consider quarterly "develop" releases, so that we
> have pressure to maintain a shippable trunk? This provides some 
opportunity
> for more releases without incurring the project maintenance costs or user
> coordination costs. Something like a feature-incomplete mid-cycle RC, that
> a user wanting shiny features can grab, providing feedback throughout the
> development cycle.
>
> On 26/01/2021, 14:11, "Benedict Elliott Smith" 
> wrote:
>
> My preference is for a simple annual major release cadence, with
> minors as necessary. This is simple for the user community and developer
> community: support = x versions = x years.
>
> I'd like to pair this with stricter merge criteria, so that we
> maintain a ~shippable trunk, and we cut a release at ~the same time every
> year, whatever features are merged. We might have to get happy with
> reverting commits that break things.
>
> I think faster cadences impose too much burden on the developer
> community for maintenance and the user community for both upgrades and
> making sense of what's going on. I think slower cadences collapse, as the
> release window begins to collect too many hopes and dreams.
>
> My hope is that we get to a point where snapshots of trunk are safe to
> run, and that major contributors are ahead of the release window for
> internal consumption, rather than behind - this might also alleviate
> pressure for hitting release windows with features.
>
>
>
>
> On 26/01/2021, 13:56, "Benjamin Lerer" 
> wrote:
>
>  Hi everybody
>
> It seems that there is a need to discuss how we will deal with
> releases
> after 4.0
> We are now relatively close from the 4.0 RC release so it make
> sense to me
> to start discussing that subject especially as it has some impact
> on some
> things like dropping support for python 2
>
> The main questions are in my opinion:
> 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?
>
> It might make sense to try a release cadence and see how it works
> out in
> practice revisiting our decision if we feel the need for it.
>
> One important thing to discuss with the cadence is the amount of
> time we
> want to support the releases. 2.2 has been supported for more than
> 5 years,
> we might not be able to support releases for a similar time frame
> if we
> release a version every 6 months for example.
> To be sure that we are all on the same page regarding what minor
> and major
> versions are and their naming: 4.1 would be a minor version
> (improvements
> and features that don't break compatibility) and 5.0 would be a
> major
> version (compatibility breakages)
>
>
>
> -
> 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

Re: [DISCUSS] Releases after 4.0

[Benjamin Lerer]

>
> My preference is for a simple annual major release cadence, with minors as
> necessary.
>

I do not think that I fully understand your proposal. How do you define a
major and a minor release?
My understanding of a major release was a version that broke some of the
compatibilities. By consequence, once a breaking change has been introduced
it will not be possible to release a minor and we will have to wait for a
major release. In a similar way if no breaking change has been introduced,
does it make sense to release a major?




On Wed, Jan 27, 2021 at 11:21 AM Benedict Elliott Smith 
wrote:

> Perhaps we could also consider quarterly "develop" releases, so that we
> have pressure to maintain a shippable trunk? This provides some opportunity
> for more releases without incurring the project maintenance costs or user
> coordination costs. Something like a feature-incomplete mid-cycle RC, that
> a user wanting shiny features can grab, providing feedback throughout the
> development cycle.
>
> On 26/01/2021, 14:11, "Benedict Elliott Smith" 
> wrote:
>
> My preference is for a simple annual major release cadence, with
> minors as necessary. This is simple for the user community and developer
> community: support = x versions = x years.
>
> I'd like to pair this with stricter merge criteria, so that we
> maintain a ~shippable trunk, and we cut a release at ~the same time every
> year, whatever features are merged. We might have to get happy with
> reverting commits that break things.
>
> I think faster cadences impose too much burden on the developer
> community for maintenance and the user community for both upgrades and
> making sense of what's going on. I think slower cadences collapse, as the
> release window begins to collect too many hopes and dreams.
>
> My hope is that we get to a point where snapshots of trunk are safe to
> run, and that major contributors are ahead of the release window for
> internal consumption, rather than behind - this might also alleviate
> pressure for hitting release windows with features.
>
>
>
>
> On 26/01/2021, 13:56, "Benjamin Lerer" 
> wrote:
>
>  Hi everybody
>
> It seems that there is a need to discuss how we will deal with
> releases
> after 4.0
> We are now relatively close from the 4.0 RC release so it make
> sense to me
> to start discussing that subject especially as it has some impact
> on some
> things like dropping support for python 2
>
> The main questions are in my opinion:
> 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?
>
> It might make sense to try a release cadence and see how it works
> out in
> practice revisiting our decision if we feel the need for it.
>
> One important thing to discuss with the cadence is the amount of
> time we
> want to support the releases. 2.2 has been supported for more than
> 5 years,
> we might not be able to support releases for a similar time frame
> if we
> release a version every 6 months for example.
> To be sure that we are all on the same page regarding what minor
> and major
> versions are and their naming: 4.1 would be a minor version
> (improvements
> and features that don't break compatibility) and 5.0 would be a
> major
> version (compatibility breakages)
>
>
>
> -
> 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
>
>

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

Perhaps we could also consider quarterly "develop" releases, so that we have 
pressure to maintain a shippable trunk? This provides some opportunity for more 
releases without incurring the project maintenance costs or user coordination 
costs. Something like a feature-incomplete mid-cycle RC, that a user wanting 
shiny features can grab, providing feedback throughout the development cycle.

On 26/01/2021, 14:11, "Benedict Elliott Smith"  wrote:

My preference is for a simple annual major release cadence, with minors as 
necessary. This is simple for the user community and developer community: 
support = x versions = x years.

I'd like to pair this with stricter merge criteria, so that we maintain a 
~shippable trunk, and we cut a release at ~the same time every year, whatever 
features are merged. We might have to get happy with reverting commits that 
break things.

I think faster cadences impose too much burden on the developer community 
for maintenance and the user community for both upgrades and making sense of 
what's going on. I think slower cadences collapse, as the release window begins 
to collect too many hopes and dreams.

My hope is that we get to a point where snapshots of trunk are safe to run, 
and that major contributors are ahead of the release window for internal 
consumption, rather than behind - this might also alleviate pressure for 
hitting release windows with features.




On 26/01/2021, 13:56, "Benjamin Lerer"  wrote:

 Hi everybody

It seems that there is a need to discuss how we will deal with releases
after 4.0
We are now relatively close from the 4.0 RC release so it make sense to 
me
to start discussing that subject especially as it has some impact on 
some
things like dropping support for python 2

The main questions are in my opinion:
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?

It might make sense to try a release cadence and see how it works out in
practice revisiting our decision if we feel the need for it.

One important thing to discuss with the cadence is the amount of time we
want to support the releases. 2.2 has been supported for more than 5 
years,
we might not be able to support releases for a similar time frame if we
release a version every 6 months for example.
To be sure that we are all on the same page regarding what minor and 
major
versions are and their naming: 4.1 would be a minor version 
(improvements
and features that don't break compatibility) and 5.0 would be a major
version (compatibility breakages)



-
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

Re: [DISCUSS] Releases after 4.0

[Benedict Elliott Smith]

My preference is for a simple annual major release cadence, with minors as 
necessary. This is simple for the user community and developer community: 
support = x versions = x years.

I'd like to pair this with stricter merge criteria, so that we maintain a 
~shippable trunk, and we cut a release at ~the same time every year, whatever 
features are merged. We might have to get happy with reverting commits that 
break things.

I think faster cadences impose too much burden on the developer community for 
maintenance and the user community for both upgrades and making sense of what's 
going on. I think slower cadences collapse, as the release window begins to 
collect too many hopes and dreams.

My hope is that we get to a point where snapshots of trunk are safe to run, and 
that major contributors are ahead of the release window for internal 
consumption, rather than behind - this might also alleviate pressure for 
hitting release windows with features.




On 26/01/2021, 13:56, "Benjamin Lerer"  wrote:

 Hi everybody

It seems that there is a need to discuss how we will deal with releases
after 4.0
We are now relatively close from the 4.0 RC release so it make sense to me
to start discussing that subject especially as it has some impact on some
things like dropping support for python 2

The main questions are in my opinion:
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?

It might make sense to try a release cadence and see how it works out in
practice revisiting our decision if we feel the need for it.

One important thing to discuss with the cadence is the amount of time we
want to support the releases. 2.2 has been supported for more than 5 years,
we might not be able to support releases for a similar time frame if we
release a version every 6 months for example.
To be sure that we are all on the same page regarding what minor and major
versions are and their naming: 4.1 would be a minor version (improvements
and features that don't break compatibility) and 5.0 would be a major
version (compatibility breakages)



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org