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 <pa...@apache.org> wrote: > 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 <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. >> > >> > >> >
