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 >>> <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. >>> > >> >>> > >> >>> > >>> >>> >>>
