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 >> <bened...@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. >> > >> > > 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: >> > >> >> > >> 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 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. >> > >> >> > >> >> > >> >> >>
