Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0 On Fri, Apr 11, 2025 at 8:22 AM Josh McKenzie wrote: > David makes a good point about making sure that we support 4.x to 6.0 > upgrades. > > Supporting live upgrades from every GA supported version > today seems obvious as a > lazy consens

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0 And David makes a good point about making sure that we support 4.x to 6.0 upgrades. Thanks, Aaron On Fri, Apr 11, 2025 at 1:03 AM guo Maxwell wrote: > +1 to 6.0 > > Berenguer Blasi 于2025年4月11日周五 13:53写道： > >> +1 6.0 >> On 10/4/25 23:57, David Capwell wrote: >> >> +1 to 6.0 >> Stron

Re: [DISCUSS] 5.1 should be 6.0

> David makes a good point about making sure that we support 4.x to 6.0 > upgrades. Supporting live upgrades from every GA supported version today seems obvious as a lazy consensus to me. Given how confusing our release versioning has been it's wort

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0 Berenguer Blasi 于2025年4月11日周五 13:53写道： > +1 6.0 > On 10/4/25 23:57, David Capwell wrote: > > +1 to 6.0 > Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades. > > On Apr 10, 2025, at 2:18 PM, C. Scott Andreas > wrote: > > +1 6.0 > > - Scott > > — > Mobile > > On Apr 10, 2025,

Re: [DISCUSS] 5.1 should be 6.0

+1 6.0 On 10/4/25 23:57, David Capwell wrote: +1 to 6.0 Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades. On Apr 10, 2025, at 2:18 PM, C. Scott Andreas wrote: +1 6.0 - Scott — Mobile On Apr 10, 2025, at 1:34 PM, Jeremy Hanna wrote:  +1 for 6.0 for TCM/Accord changes, maki

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0 Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades. > On Apr 10, 2025, at 2:18 PM, C. Scott Andreas wrote: > > +1 6.0 > > - Scott > > — > Mobile > >> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna wrote: >> >> +1 for 6.0 for TCM/Accord changes, making it easier to make a case

Re: [DISCUSS] 5.1 should be 6.0

+1 6.0- Scott—MobileOn Apr 10, 2025, at 1:34 PM, Jeremy Hanna wrote:+1 for 6.0 for TCM/Accord changes, making it easier to make a case to upgrade dependencies like the Java/Python versions.On Apr 10, 2025, at 3:24 PM, Bernardo Botella wrote:+1 on 6.0On Apr 10, 2025, at 1:07 PM, Josh McKenzie wr

Re: [DISCUSS] 5.1 should be 6.0

+1 for 6.0 for TCM/Accord changes, making it easier to make a case to upgrade dependencies like the Java/Python versions. > On Apr 10, 2025, at 3:24 PM, Bernardo Botella > wrote: > > +1 on 6.0 > >> On Apr 10, 2025, at 1:07 PM, Josh McKenzie wrote: >> >> Let's keep this thread to just +1's o

Re: [DISCUSS] 5.1 should be 6.0

+1 on 6.0 > On Apr 10, 2025, at 1:07 PM, Josh McKenzie wrote: > > Let's keep this thread to just +1's on 6.0; I'll see about a proper isolated > [DISCUSS] thread for my proposal above hopefully tomorrow, schedule > permitting. > > On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote: >> +1

Re: [DISCUSS] 5.1 should be 6.0

Let's keep this thread to just +1's on 6.0; I'll see about a proper isolated [DISCUSS] thread for my proposal above hopefully tomorrow, schedule permitting. On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote: > +1 to 6.0 > > On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie wrote: >> __ >> +1

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0 On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie wrote: > +1 to 6.0. > > On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote: > > Bringing this back up. > > I don't think we have any reason to hold up renaming the version. We can > have a separate discussion about what upgrade paths are s

Re: [DISCUSS] 5.1 should be 6.0

IIRC one of the reasons that was raised to bump to 5.0 was because of Accord. We realised latter when we pushed TCM and Accord out that the version bump may have been premature (though the other opinion around versioning remains around what upgrade paths we say we support being based on what upgra

Re: [DISCUSS] 5.1 should be 6.0

I don’t think there is any world where we can justify such major changes being called 5.1. 5.0 had significantly less major changes. Mick, the topics you bring up are important. But I don’t think they are required for the community to decide we are calling this 6.0. We’ve tried that approach and we

Re: [DISCUSS] 5.1 should be 6.0

I am +1 on 6.0 as well. The other topics brought up on this thread are important, and we should address them, but I think we can move forward with the version decision in parallel. Jordan On Thu, Apr 10, 2025 at 11:50 AM Brad wrote: > > . I assume JDK 21 may lead to removal of JDK 11 which is b

Re: [DISCUSS] 5.1 should be 6.0

Rather than only tackle this one-off, can we please put energy into Josh's proposal raised above. This discussion has both technical implications (tcm, accord, jdk21, jvm-dtest-upgrades, …), legitimate external-facing communication concerns, and people's general opinions. I thought Josh's propos

Re: [DISCUSS] 5.1 should be 6.0

> . I assume JDK 21 may lead to removal of JDK 11 which is breaking change If we name it 6.0, I would hope we bump both Java and Python supported versions to align with their EOL status. - Java 11 with OpenJDK EOL was October 2024 - Python 3.8 EOL was October 7, 2024 On Thu, Apr 10, 2025

Re: [DISCUSS] 5.1 should be 6.0

+1 on calling it 6.0. I assume JDK 21 may lead to removal of JDK 11 which is breaking change (people need to upgrade to the common JDK version - 17 before upgrading to the next release) On Thu, 10 Apr 2025 at 14:40, Štefan Miklošovič wrote: > +1, I am also getting questions about the versioning

Re: [DISCUSS] 5.1 should be 6.0

+1, I am also getting questions about the versioning recently and people themselves do not know what to call the next version like. On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad wrote: > Bringing this back up. > > I don't think we have any reason to hold up renaming the version. We can > have a se

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0. On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote: > Bringing this back up. > > I don't think we have any reason to hold up renaming the version. We can > have a separate discussion about what upgrade paths are supported, but let's > at least address this one issue of version numbe

Re: [DISCUSS] 5.1 should be 6.0

Bringing this back up. I don't think we have any reason to hold up renaming the version. We can have a separate discussion about what upgrade paths are supported, but let's at least address this one issue of version number so we can have consistent messaging. When i talk to people about the next

Re: [DISCUSS] 5.1 should be 6.0

. > If you mean only 4.1 and 5.0 would be online upgrade targets, I would > suggest we change that to T-3 so you encompass all “currently supported” > releases at the time the new branch is GAed. > > I think that's better actually, yeah. I was originally thinking T-2 from > the "what calendar

Re: [DISCUSS] 5.1 should be 6.0

Josh - from a community / user perspective, I think what you just described is a win. I have no clue what it means in the context of the actual work that needs to be done, so I'll leave that aspect to others to comment on. I could see a world where a 5.1 makes sense - but only if it was offering

Re: [DISCUSS] 5.1 should be 6.0

On Jan 29, 2025 at 3:32:13 PM, Josh McKenzie wrote: > My opinion is that it would be valuable to take this discussion as a > forcing function to determine how we plan to handle releases broadly to > answer the "5.1 should be 6.0" question. Assuming we move away from ad hoc > per-release debate. I

Re: [DISCUSS] 5.1 should be 6.0

My opinion is that it would be valuable to take this discussion as a forcing function to determine how we plan to handle releases broadly to answer the "5.1 should be 6.0" question. Assuming we move away from ad hoc per-release debate. If there's broad strong dissent (i.e. let's have 6.0 be the

Re: [DISCUSS] 5.1 should be 6.0

This got way off topic from 5.1 should be 6.0, so maybe there should be a new DISCUSS thread with the correct title to have a discussion around codifying our upgrade paths? FWIW this mostly agrees with my thoughts around upgrade support. T-2 online upgrade supported, T-1 API compatible, deprecat

Re: [DISCUSS] 5.1 should be 6.0

To clarify, when I say unspoken it includes "not consciously considered but shapes engagement patterns". I don't think there's people sitting around deeply against either the status quo or my proposal who are holding back for nefarious purposes or anything. And yeah - my goal is to try and put

Re: [DISCUSS] 5.1 should be 6.0

I think you’re making the mistake of assuming a representative sample of the community participates in these debates. Sensibly, a majority of the community sits these out, and I think on this topic that’s actually the rational response. That doesn’t stop folk voting for something else when the d

Re: [DISCUSS] 5.1 should be 6.0

I've let this topic sit in my head overnight and kind of chewed on it. While I agree w/the "we're doing what matches our unspoken incentives" angle Benedict, I think we can do better than that both for ourselves and our users if we apply energy here and codify something. If people come out with

Re: [DISCUSS] 5.1 should be 6.0

I agree there’s probably some value captured in having ccm tests, but I suspect not in most of the python tests we have, which are all but unmaintained at this point. When I looked at them last I was surprised at how rubbish many of them were. I think we need a plan to maintain them properly, a

Re: [DISCUSS] 5.1 should be 6.0

I have not checked Jenkins, but we see this in another environment… For python upgrades have we actually audited the runtime to see that the time spent is doing real work? Josh and I have spent a ton of time trying to fix (and failing) an issue where the python driver blocks the test and we wai

Re: [DISCUSS] 5.1 should be 6.0

> We revisit this basically every year and so I’m sort of inclined to keep the > status quo which really amounts to basically doing whatever we end up > deciding arbitrarily before we actually cut a release. > > Before discussing at length a new policy we’ll only immediately break It's painful

Re: [DISCUSS] 5.1 should be 6.0

My opinion? Our revealed preferences don’t match whatever ideal is being chased whenever we discuss a policy. . Ignoring the tick-tick debacle the community has done basically the same thing every release, only with a drift towards stricter QA and compatibility expectations with maturity. That

Re: [DISCUSS] 5.1 should be 6.0

replies inline… . We have far fewer (and more effective?) JVM Upgrade DTests. > There we only need 8x medium (3 cpu, 5GB ram) servers > > Does anyone have a strong understanding of the coverage and value offered > by the python upgrade dtests vs. the in-jvm dtests? I don't, but I > intuitively h

Re: [DISCUSS] 5.1 should be 6.0

Won't comment directly on the compatibility window (although I lean toward the status quo and just requiring upgrades from the latest patch version of a major release), but I think I've also arrived at a point where I'm not convinced running the Python upgrade tests pre-commit is an efficient use o

Re: [DISCUSS] 5.1 should be 6.0

We revisit this basically every year and so I’m sort of inclined to keep the status quo which really amounts to basically doing whatever we end up deciding arbitrarily before we actually cut a release. Before discussing at length a new policy we’ll only immediately break, if the motivation is

Re: [DISCUSS] 5.1 should be 6.0

> Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers > We have far fewer (and more effective?) JVM Upgrade DTests. > There we only need 8x medium (3 cpu, 5GB ram) servers Does anyone have a strong understanding of the coverage and value offered by the python upgrade dtests

Re: [DISCUSS] 5.1 should be 6.0

Jordan, replies inline. To take a snippet from your email "A little empathy for our users goes a > long way." While I agree clarity is important, forcing our users to > upgrade multiple times is not in their best interest. > Yes – we would be moving in that direction by now saying we aim for o

Re: [DISCUSS] 5.1 should be 6.0

Yeah, my position is this isn’t a problem. The full range of upgrade tests only need to be run at most on release, and we’re not talking about supporting loads of versions. I think it’s fine to (as before) expect people upgrade from and to the highest patch version of any minor release, so the m

Re: [DISCUSS] 5.1 should be 6.0

Mick, There is a lot to respond to here and I think we might need a few other threads to avoid a spidering conversation but I wanted to respond to what I saw is at least part of the crux of your concern: our recommended upgrade paths. To take a snippet from your email "A little empathy for our use

Re: [DISCUSS] 5.1 should be 6.0

There's still a few open loops in this thread that I'd like to keep pushing on. I admit I've been pretty adamant that there's real value for a) users, operators, and ourselves, having an intuitive understanding of our recommended upgrade paths by versions, and b) a method to reduce the CI testing

Re: [DISCUSS] 5.1 should be 6.0

> My expectation is that in trunk SCM CASSANDRA_4 would change to SCM > CASSANDRA_5. Assuming you upgrade from 4.0 to 5.0, then you are running on CASSANDRA_4… how many people know that they are expected to do something about that (Sam documented the steps earlier)? What if you leave things al

Re: [DISCUSS] 5.1 should be 6.0

No, we initially tried to preserve all the previous paths and put the whole thing behind a feature flag, but it was just way too pervasive and doing so would've added years to the project. So for the period before the CMS is initialized, certain operations are not available. However, it should

Re: [DISCUSS] 5.1 should be 6.0

My expectation is that in trunk SCM CASSANDRA_4 would change to SCM CASSANDRA_5. I think we should be striving to support full downgrade/rollback ability to the previous major version from trunk. With TCM I would expect that when running in CASSANDRA_5 mode that initializing TCM would not be poss

Re: [DISCUSS] 5.1 should be 6.0

I think there is a danger that when in comes to the next upgrade cycle there could be production clusters still running in CASSANDRA_4 mode, as the operators haven’t realised they need to move through the SCM levels. The default setting for a new cluster is CASSANDRA_4 and unless a new operator

Re: [DISCUSS] 5.1 should be 6.0

My point is that the upgrade to 5.1/6.0 isn't really complete until the CMS is initialised and this can't be done while running with SCM CASSANDRA_4 because of the messaging service limitation. Until that point, schema changes & node replacements are not supported which affects how long a bake t

Re: [DISCUSS] 5.1 should be 6.0

On Wed, Dec 11, 2024 at 7:22 AM Sam Tunnicliffe wrote: > > so running in any SCM mode for a prolonged period is not really viable. This is what many users want to do though, upgrade one DC and let it bake to see how it goes before continuing. I don't think that's unreasonable, but from working o

Re: [DISCUSS] 5.1 should be 6.0

At present, there is one version specific mode - CASSANDRA_4. Fully utilising SCM during an upgrade though requires first a "soft" upgrade into CASSANDRA_4 mode, then a full cluster bounce into UPGRADING mode and finally another into NONE. I think that as the list of versions we want to provide

Re: [DISCUSS] 5.1 should be 6.0

It might not be too bad if done selectively? I agree that would be infeasible for each patch. How many SCM modes do we have? I worry more about developer burden. It sounds like we have a balancing act with SCM complexity versus upgrade complexity. I think at the very least we should require th

Re: [DISCUSS] 5.1 should be 6.0

Staying slightly off topic - we'd also have to run upgrade tests for all these upgrade combinations, including different storage compatibility mode settings, that is going to be very expensive. /Marcus On Wed, Dec 11, 2024 at 12:36:02PM GMT, Sam Tunnicliffe wrote: > Maybe this is not the right

Re: [DISCUSS] 5.1 should be 6.0

Maybe this is not the right place to bring up practicalities, but the more upgrade paths we support the more complexity we take on. The ongoing issues mentioned in CASSANDRA-20118 are illustrative and the introduction of Storage Compatibility Mode adds further dimensions and operational complexi

Re: [DISCUSS] 5.1 should be 6.0

+1 for calling it 6, even if just to bring up to people on 2.x,3.x that they are on "ancient" code. Sent via Superhuman iOS On Wed, Dec 11 2024 at 5:23 AM, Aleksey Yeshchenko wrote: > We don’t really practice canonic sermver, we never really have, a

Re: [DISCUSS] 5.1 should be 6.0

We don’t really practice canonic sermver, we never really have, and it’s impossible to properly follow anyway. Should be perfectly fine to bump to 6.0, so long as we don’t take the bump as a license to break compatibility in a way that we wouldn’t have for 5.1. > On 11 Dec 2024, at 00:11, Jon

Re: [DISCUSS] 5.1 should be 6.0

> A lot has already been cleaned in 4.0 that makes 3.x to 5.x now non-functioning. And the cleaner code certainly helps navigate the code base quicker. Sure - I was using that as an example, looking back in hindsight. Like, if today people could go from 2.1 -> 5.0 it would be cool. Applying it

Re: [DISCUSS] 5.1 should be 6.0

I know a few teams on 2.2 that would *love* to be able to jump right to > 5.0. Once you fall far enough behind, upgrading to another version that's > already deprecated becomes paralyzing. I don't expect 2.2 compatibility > btw, just using it as an example. > > If it can be done, it would make a

Re: [DISCUSS] 5.1 should be 6.0

I have to agree. Harder upgrades are simpler for users? No chance.I like Jeremiah’s proposal, but would also be happy with a less rigid “we support as many versions as we can without it becoming a burden” - which for some versions might be one minor/major, and for others might be three or more.On 1

Re: [DISCUSS] 5.1 should be 6.0

I know a few teams on 2.2 that would *love* to be able to jump right to 5.0. Once you fall far enough behind, upgrading to another version that's already deprecated becomes paralyzing. I don't expect 2.2 compatibility btw, just using it as an example. If it can be done, it would make a lot of fo

Re: [DISCUSS] 5.1 should be 6.0

I think the simplest upgrade path is actually “you can upgrade from any currently ’supported’ version to this new one”. So for 5.1/6.0 that would be 4.0/4.1/5.0. That has always been my preferred support model for upgrades. -Jeremiah On Dec 10, 2024 at 3:45:52 PM, Mick Semb Wever wrote: > >

Re: [DISCUSS] 5.1 should be 6.0

I would very much rather keep our upgrade paths simple and intuitive: You can only upgrade between adjacent major versions. This does catch users, and keeping it simple has helped a lot. I find it helps internally working on the code too, with a focus on stability for online upgrades, which does q

Re: [DISCUSS] 5.1 should be 6.0

Usually, a major release would bump the Java and Python supported versions. Both Java and Python are on well-published and faster release cycles. On Tue, Dec 10, 2024 at 3:40 PM Paulo Motta wrote: > I share this sentiment. Outside of marketing and API compatibility > considerations, I think the

Re: [DISCUSS] 5.1 should be 6.0

The only thing the version numbers communicate for upgrades is a minimum guarantee. Just as we allowed 3.x to 5.0 we can and should allow 4.x to 6.0. If anything I would like to see us move towards a norm of supporting upgrade across more milestone releases as standard.On 10 Dec 2024, at 20:16, Cal

Re: [DISCUSS] 5.1 should be 6.0

I share this sentiment. Outside of marketing and API compatibility considerations, I think the changes are significant enough to warrant a major version bump, since it represents a new generation of the database. On Tue, Dec 10, 2024 at 1:02 PM Brandon Williams wrote: > Even if TCM is api-compat

Re: [DISCUSS] 5.1 should be 6.0

I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are possible. On Tue, Dec 10, 2024 at 1:28 PM David Capwell wrote: > Given our version support… if we do make this change does this imply users > must do the following to get to 6.0? > > 4.x upgrade to 5.0 > 5.0 upgrade to 6.0 > > S

Re: [DISCUSS] 5.1 should be 6.0

Given our version support… if we do make this change does this imply users must do the following to get to 6.0? 4.x upgrade to 5.0 5.0 upgrade to 6.0 So no 4.x to 6.0? Given that this is 5.1 atm we are expected to support 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off our

Re: [DISCUSS] 5.1 should be 6.0

> This is another topic we basically revisit afresh every time :) > > I think it’s fine to bump for marketing or vibe reasons, I would support it. > I don’t think we need to confect some weak semverish justification. Vibes ftw. Lets see if any strong contradicting opinions pop up on here in the

Re: [DISCUSS] 5.1 should be 6.0

I was waiting for this discussion to happen again. :p What you call marketing, I call end-user communication. I'll leave this open question, but what do we want to communicate to the user base, and how should they approach this new feature set? Patrick On Tue, Dec 10, 2024 at 10:10 AM Benedict E

Re: [DISCUSS] 5.1 should be 6.0

6.0 even just for the reasons Brandon mentioned sounds reasonable to me. And I acknowledge there are more On Tue, 10 Dec 2024 at 13:10, Benedict Elliott Smith wrote: > This is another topic we basically revisit afresh every time :) > > I think it’s fine to bump for marketing or vibe reasons, I w

Re: [DISCUSS] 5.1 should be 6.0

This is another topic we basically revisit afresh every time :) I think it’s fine to bump for marketing or vibe reasons, I would support it. I don’t think we need to confect some weak semverish justification. > On 10 Dec 2024, at 13:01, Brandon Williams wrote: > > Even if TCM is api-compatibl

Re: [DISCUSS] 5.1 should be 6.0

Even if TCM is api-compatible, it will change how operators run Cassandra in a significant way (like, different procedures from every previous version.) I think that justifies a major. Kind Regards, Brandon On Tue, Dec 10, 2024 at 11:51 AM Jeff Jirsa wrote: > > You’ve added a ton of API surface

Re: [DISCUSS] 5.1 should be 6.0

You’ve added a ton of API surface to transaction behavior and cluster management. The TCM may or may not be strictly breaking, but they’re fundamentally very very different, so even with semver as the only standard, I think you can justify a major. But also, let’s just acknowledge that marketin

Re: [DISCUSS] 5.1 should be 6.0

Currently we reserve MAJOR in semver changes for API breaking only: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting: That's consistent w/semver itself: link : > Given

Re: [DISCUSS] 5.1 should be 6.0

The question is if we are signaling compatibility or purely marketing with the release number. We dropped compatibility with a few things in 5.0, which was the reason for the .0 rather than 4.2. I don’t know if we are breaking any compatibility with current trunk? Though maybe some of the TCM st

[DISCUSS] 5.1 should be 6.0

Keeping this short. I'm not sure why we're calling the next release 5.1. TCM and Accord are a massive thing. Other .1 / .2 releases were the .0 with some smaller things added. Imo this is a huge step forward, as big as 5.0 was, so we should call it 6.0.