> Convenience features like CEP-37. This isn't solving an issue that existing > operators haven't already had to solve with some external tool such as Reaper. I wish this were true. Every time Patrick's surveyed the community and in every other dataset I've seen the number of operators who don't run repair is horrifying. CEP-37 is kind of unique in that respect; I can't think of any other major fundamental gaps in functionality we've just foisted on our users like repair.
So zooming out to confirm we're aligned on the big picture: 1. What is the problem we're trying to solve? 2. Why does that problem exist? This will inform: 3. How do we want to solve that problem? My understanding right now: 1. There's a lot of duplicate effort going into maintaining private backport forks of the database. This effort could instead go to public collaboration lowering the burden on everyone and increasing value to our users and ecosystem and people would prefer that. 2. Because **the perception of** upgrading major versions of C* remains difficult and dangerous (we should explore this more). I say "perception of" because there seems to be differing views here of where we are right now. 3. This thread is suggesting we solve that problem via making a backport branch/release public and a 1st class citizen A backport branch is really a workaround to separate perceived lower risk features from higher risk. Another approach would be to discuss and agree upon a set of criteria we will apply to all new features before merging to lower the risk of adoption. This would not resolve any currently merged features that don't yet meet that bar; contributors would need to step up and bring all currently merged features into compliance to bring trunk into a state where operators and non-authors would be comfortable running a release cut from it. On Mon, Oct 13, 2025, at 8:52 AM, Michael Burman wrote: > I feel like this thread only highlights the problems with the current release > model and how long it takes to get the next version out. Maybe that's because > of feature creep or development model itself (too many changes in a single > version), but clearly there's so many contradicting wishes in the thread that > in my opinion the entire idea of -backports branch starts to make no sense. > I'm probably just repeating what others have said, but here's one more > opinion. > > So far I've seen three different categories. > > 1. Runtime impact, such as JDK 21 support. Since JDK17 is soon EOL for some > support companies, personally this is already starting to feel like a bug > that it's not supported in the 5.0 branch. This directly impacts the user's > ability to run on supported platforms. Sure, some providers do support until > Sep/Oct 2027, but that's not far away if people wish to migrate from older > versions of Cassandra as they might have to instantly start running an > unsupported base OS or buy support from external vendor. Personally, this has > been the only thing here that I see as "this really is relevant backport to > stable branch" in this discussion. > 2. Major features like TCM/Accord. Isn't these types of "breaking" changes > exactly why we change major version number? It's also something that we want > to advertise as major features not available in earlier versions. If we port > back everything fancy from 6.0 to 5.1, then why release 6.0 at all? Just call > it 5.1 then. > 3. Convenience features like CEP-37. This isn't solving an issue that > existing operators haven't already had to solve with some external tool such > as Reaper. I don't see how this would make migrations easier as they already > have a solution in place for 4.1 which works as is for their 5.0 cluster > also. The next major version solving this is again a nice thing to advertise > as a bonus and should make people more eager to update. Starting backport of > these convenience features opens a floodgate, everyone then wants something > nice like the split of YAML files and suddenly something "innocent" starts > breaking entire clusters because a certain edge case that used to work > doesn't suddenly work. "No one uses this.." This has happened in the past. > > Faster release cadence would probably be my favourite choice, but it has its > own issues with support policy also and probably should be done in a separate > discussion. As Josh said in the first message, there's clearly a lot of > examples (I would have said FreeBSD since it has a very long history of doing > this, but it is a slightly different model also) but I also think it's a bit > late for these at this stage and would make more sense to do after releasing > 6.0 and before beginning a new cycle. At that point it would be easier to > modify the process to include 7.0+6.1 for example as then it would be clear > to the end users also what kind of releases to expect. Now there's been so > many changes to the trunk already that this is going to require a lot of work > and 5.0 has been out for over a year. > > - Micke > > On Mon, 13 Oct 2025 at 14:02, Štefan Miklošovič <[email protected]> > wrote: >> I agree with all of that, Alex. >> >> Plus, I am not completely sure how that would look like in practice, >> e.g. porting TCM to 5.0, (maybe somebody already has a fork like that >> so they can elaborate more), but my guess is that thing like that >> would be quite tricky to backport. All I am saying is that it might be >> more work than anticipated, then we would be porting for next half a >> year with all "ah we need to tweak this here as well to have backport >> right" and it might actually produce way more work than if somebody >> just upgraded and be done with it. >> >> On Mon, Oct 13, 2025 at 11:04 AM Alex Petrov <[email protected]> wrote: >> > >> > > For instance, when upgrading to 5.1, a lack of a straightforward >> > > rollback path can make the process risky. >> > >> > @Jaydeep Chovatia, could you elaborate on this, since to my best knowledge >> > there _is_ a straightforward rollback path for the features I am aware of. >> > You can enable Accord transactions and later disable them, and you can >> > also migrate back to Gossip from TCM. Both of these upgrade/downgrade >> > paths are thoroughly tested. If there are other features that lack >> > downgrade path, please mention them. >> > >> > On Sun, Oct 12, 2025, at 9:12 PM, Jaydeep Chovatia wrote: >> > >> > Here is my opinion. >> > >> > >– Unofficial branches will miss correctness and compatibility fixes >> > >unless their maintenance is made a burden for all committers. If not, >> > >they’ll be buggier and more prone to data loss than trunk. >> > >> > Typically, the backporting effort is handled by the author or co-author of >> > a given CEP. As long as they are motivated to pursue the backport, I don’t >> > anticipate this being a concern. In most cases, their motivation naturally >> > comes from the fact that they are themselves relying on or benefiting from >> > the backported version. >> > >> > >– The upgrade matrix becomes more complicated. As features are >> > >backported, any change affecting internode messaging, config properties, >> > >etc. becomes a potential compatibility breakage on upgrade, and these >> > >upgrade paths will be untested and unexercised. >> > >– There’s an assumption in this thread that backports are easy to pick >> > >up. Backporting is often not straightforward and requires a high degree >> > >of understanding of the surrounding context, integration points, and >> > >what’s changed across branches. >> > >> > As discussed earlier, we should conduct a formal vote on any proposed >> > backports and exercise caution with those that alter internal >> > communication mechanisms, Gossip protocols, or introduce backward >> > incompatibilities. Backports should meet a higher threshold—either by >> > addressing fundamental gaps in the database framework or by delivering >> > substantial reliability/efficiency improvements. For instance, CEP-37 and >> > JDK 17/21 are strong candidates for backporting: the former is essential >> > to maintaining data correctness in Cassandra, while the latter has become >> > necessary as much of the industry has already transitioned beyond JDK 11. >> > >> > >– The proposal runs counter to the goal of “people running the database >> > >and finding + fixing issues.” I happily run trunk, but I don’t want to be >> > >the only one running trunk if others are committing changes to it. >> > >Committing changes to trunk then backporting them to releases considered >> > >“stable” doesn’t produce a more stable database. >> > >– Backports branches don’t solve the “some people run forks” problem. >> > >– Increasing the user community’s confidence in running new releases of >> > >the database. A lot of people are reluctant to upgrade, but it’s so much >> > >safer and easier than since the 2.x/3.x days. We want people to be >> > >confident running new releases of the database, not clinging to a branch. >> > >– Deploying trunk and reporting back. Contributors of new features they’d >> > >like to backport should deploy and operate trunk. It’s the best way to >> > >establish confidence and makes Cassandra better for everybody. >> > >> > I must acknowledge that the upgrade process has come a long way since the >> > 2.x and 3.x versions, but there’s still room for improvement. For >> > instance, when upgrading to 5.1, a lack of a straightforward rollback path >> > can make the process risky. This limitation often slows modernization >> > efforts, as teams are understandably hesitant to proceed without a >> > reliable fallback. Many businesses around the world run critical workloads >> > on Cassandra, and an outage caused by an upgrade would ultimately fall on >> > the decision makers—making them cautious about taking such risks. >> > This concern is precisely why many decision makers prefer to backport >> > features (such as CEP-37, JDK 17/21) and operate on private forks rather >> > than upgrade to 5.1. This proposal aims to make their lives easier by >> > providing an official and coordinated path for backporting, rather than >> > leaving each operator to maintain their own fork. For example, support for >> > JDK 17 or 21 on version 4.1 is already a widespread need among operators. >> > We should certainly begin a new discussion on how to make our upgrade/new >> > versions process safer, so that, in the long run, the need for backporting >> > and similar discussions is eliminated. >> > >> > >– Increasing release velocity. We do need to improve here and I’d be open >> > >to 5.1. >> > >> > I am not sure that’s the case. For most decision makers, the primary >> > concern isn’t velocity but safety. The key question they ask themselves >> > is, ‘What is my fallback plan?’ If that plan appears uncertain or risky, >> > they are understandably hesitant to proceed with an upgrade. >> > >> > >> > Jaydeep >> > >> > On Sun, Oct 12, 2025 at 9:04 AM <[email protected]> wrote: >> > >> > I don’t think we have consensus on this thread, but it feels like some are >> > pushing forward as if we do (“If everybody is generally onboard with the >> > proposal, we can start getting into the details of the logistics…,” >> > followed by discussion of logistics). >> > >> > The thread also contains multiple different proposals: new feature >> > backports branches, liberalizing feature backports to stable releases, >> > cutting 5.1 now, or stay the course. >> > >> > I don’t support creation of new backports branches, but will keep my >> > thoughts brief since there’s a lot of discussion: >> > >> > – The CI burden of existing branches is really high. Either new branches >> > are treated as first-class and impose stability burdens on committers, or >> > they fall into disrepair and are unsuitable for releases. Release >> > engineering for a branch is nearly a full-time job. >> > – Unofficial branches will miss correctness and compatibility fixes unless >> > their maintenance is made a burden for all committers. If not, they’ll be >> > buggier and more prone to data loss than trunk. >> > – The upgrade matrix becomes more complicated. As features are backported, >> > any change affecting internode messaging, config properties, etc. becomes >> > a potential compatibility breakage on upgrade, and these upgrade paths >> > will be untested and unexercised. >> > – There’s an assumption in this thread that backports are easy to pick up. >> > Backporting is often not straightforward and requires a high degree of >> > understanding of the surrounding context, integration points, and what’s >> > changed across branches. >> > – The proposal runs counter to the goal of “people running the database >> > and finding + fixing issues.” I happily run trunk, but I don’t want to be >> > the only one running trunk if others are committing changes to it. >> > Committing changes to trunk then backporting them to releases considered >> > “stable” doesn’t produce a more stable database. >> > – Pitching this as a limited-time pilot doesn't these problems, and it >> > introduces new ones. The user community would fragment across these >> > branches and have to be reconverged despite untested upgrade paths if the >> > pilot were wound down. >> > – Backports branches don’t solve the “some people run forks” problem. >> > – Backports branches don’t solve the user community adoption problem >> > either, unless we’re also publishing per-OS packages, Maven artifacts, etc. >> > >> > For me, the proposal wouldn't achieve its stated goal and introduces many >> > new issues. But I do strongly support that goal. >> > >> > Toward bringing stable features into the user community’s hands more >> > quickly, the fix for this seems like: >> > >> > – Increasing the user community’s confidence in running new releases of >> > the database. A lot of people are reluctant to upgrade, but it’s so much >> > safer and easier than since the 2.x/3.x days. We want people to be >> > confident running new releases of the database, not clinging to a branch. >> > – Deploying trunk and reporting back. Contributors of new features they’d >> > like to backport should deploy and operate trunk. It’s the best way to >> > establish confidence and makes Cassandra better for everybody. >> > – Increasing release velocity. We do need to improve here and I’d be open >> > to 5.1. >> > – Exercising our existing consensus-based approach of backporting stable >> > and well-contained enhancements to earlier branches following discussion >> > on the mailing list. We could do this a little more often. >> > >> > – Scott >> > >> > On Oct 12, 2025, at 8:28 AM, Chris Lohfink <[email protected]> wrote: >> > >> > But it should include all features from trunk that we consider to be >> > production ready (that includes TCM in my book) >> > >> > >> > Please no TCM/accord. That is why everyone will be on 5.0/5.1 for years. >> > I'll be the person to say it outloud. I'm happy to be proven wrong but >> > let's be realistic. >> > >> > Chris >> > >> >
