Re: [DISCUSS] 5.1 should be 6.0

Tue, 10 Dec 2024 14:40:58 -0800

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 10 Dec 2024, at 22:10, Jon Haddad <j...@rustyrazorblade.com> wrote:


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 folks very happy.

@Mick, you made me laugh, with your unique ability to agree disagreeably.   You might not care about marketing, but people pay more attention to major version upgrades and "minor" ones.  Even though this can be in no way be considered a minor change.  It doesn't matter what people "should" do.  Major version bump is a signal to end users that this is a BIG DEAL.

Jon



On Tue, Dec 10, 2024 at 1:58 PM Jeremiah Jordan <jeremiah.jor...@gmail.com> wrote:
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 <m...@apache.org> wrote:

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 quickly become messy.

I'm open to the suggestion that TCM changes enough that it warrants it, and if we're ok imposing onto the user that this change means they have to upgrade from 4.x to 5.0 before 6.0.  Major upgrades are not trivial, we see enterprises often need 6 months.

I would much rather use the introduction of Java21 and the removal of Java11 as the compatibility change that warrants the bump to 6.0.  I haven't thought about Python here, I don't think it applies as it's not a server-side change that we recommend the operator avoid making at the same time as an upgrade.

On the bikeshedding front: I'm against major version bumps for feature marketing reasons.  A leading number is not required to sell features as significant as Accord and TCM.  It's a personal opinion, but it just feels desperate and lacking in confidence for a technology as established as C*. Let the work speak for itself.

  

On Wed, 11 Dec 2024 at 07:16, Caleb Rackliffe <calebrackli...@gmail.com> wrote:
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 <dcapw...@apple.com> 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

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 documentation

On Dec 10, 2024, at 11:00 AM, Josh McKenzie <jmcken...@apache.org> wrote:

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 next few days; if not I'll draft up a revision to the wiki. Taking it on a case-by-case release basis w/a respect for vibes sounds perfect to me.

On Tue, Dec 10, 2024, at 1:37 PM, Patrick McFadin wrote:
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 Elliott Smith
>
> 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 <dri...@gmail.com> wrote:
> >
> > 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 <jji...@gmail.com> wrote:
> >>
> >> 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 marketing is a thing and bump the major to acknowledge the huge, massive, database-changing features, even if they’re not meant to be disruptive.
> >>
> >>
> >>
> >> On Dec 10, 2024, at 9:46 AM, Josh McKenzie <jmcken...@apache.org> wrote:
> >>
> >>
> >> That's consistent w/semver itself: link:
> >>
> >> Given a version number MAJOR.MINOR.PATCH, increment the:
> >>
> >> MAJOR version when you make incompatible API changes
> >> MINOR version when you add functionality in a backward compatible manner
> >> PATCH version when you make backward compatible bug fixes
> >>
> >>
> >> So absolute literal "correctness" of what we're doing aside, our version numbers mean something to us as a dev community but also mean something to Cassandra users. I'm not confident they mean the same thing to each constituency. I'm also not comfortable with us prioritizing our own version number needs over that of our users, should they differ in meaning.
> >>
> >> Does anybody have insight into how other well known widely adopted projects do things we might be able to learn from? I generally only think about this topic when a discussion like this comes up on our dev list so don't have much insight to bring to the discussion.
> >>
> >> On Tue, Dec 10, 2024, at 11:52 AM, Jeremiah Jordan wrote:
> >>
> >> 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 stuff could be considered that.
> >> If we are purely going for marketing value, then yes, I agree TCM+Accord would be 6.0 worthy.
> >>
> >> -Jeremiah
> >>
> >> On Dec 10, 2024 at 10:48:21 AM, Jon Haddad <j...@rustyrazorblade.com> wrote:
> >>
> >> 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.
> >>
> >>
>

Reply via email to