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.