Pushing CASSANDRA-16262 out of 4.0-rc

Hey everyone, I wanted to have a quick conversation about CASSANDRA-16262 . As I mentioned in the Jira

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

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

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] When to stop supporting Python 2

>From the "Supported upgrade path for 4.0" discussion, it seems like there was consensus around supporting the "3.0 -> 4.0" upgrade path as well (in addition to 3.11 -> 4.0), so we may need to add python3 support for 3.0 as well? Internally. we had a need to make 3.0 cqlsh python3 compatible, and

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

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

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

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

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

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

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

Re: [DISCUSS] When to stop supporting Python 2

Considering the issue with pip. I agree that we should remove support for 3.0 and ensure that python 3 is supported by 3.11. On Wed, Jan 27, 2021 at 8:18 PM Jonathan Ellis wrote: > Python 2 was EOLed over a year ago. I think it's fine to (1) require > python 3 to run cqlsh and (2) remove code