Re: [DISCUSS] Releases after 4.0

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 pri

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

Where did we land on this? Joey's statement above: > * 4.0: Fully supported until April 2023 and high severity bugs until April > 2024 (2 year full, 1 year bugfix) > * 3.11: Fully supported until April 2022 and high severity bugs until > April 2023 (1 year full, 1 year bugfix) > * 3.0: Supported f

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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 seem

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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 Lere

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

+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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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 suppo

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

> 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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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 shou

Re: [DISCUSS] Releases after 4.0

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 p

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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 envisag

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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 guideli

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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

Re: [DISCUSS] Releases after 4.0

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 a

[DISCUSS] Releases after 4.0

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 q