I want to stress that I would like 5.1 be with strictly limited on backported features, as I have written in my last email. It should really be just Java 21 and CEP-37 and that’s it (plus bugfixes).
I do want to avoid the situation when various people (I already see some) are trying to ask if this and that will be backported. I really want to prevent features be backported extensively. We need to put some reasonable limit on this otherwise we will be experiencing constant nagging of the community why this or that is not backported and potentially severely preventing 6.0 from broader adoption. Plus the nagging might be so strong that after a while 5.1 will be beyond recognition and it will be something nobody actually wanted to happen. I want this to be part of the vote, what goes in, if we ever go vote on this proposal (we should). Nothing like “we will see”. No, let’s plan 5.1 ahead and just stick to that for the sake of the simplicity and at least some kind of predictability. Regards From: Josh McKenzie <[email protected]> Date: Wednesday, 15 October 2025 at 14:13 To: dev <[email protected]> Subject: Re: [DISCUSS] Pilot program of an officially supported backport branch EXTERNAL EMAIL - USE CAUTION when clicking links or attachments 1.) Should we have a mechanism to backport CEP-37, Java 21, and things like them, that do not introduce messaging or on-disk version changes? Yes (though we already agreed to JDK21 on another discussion separately) 2.) Where should those backports happen? (An existing major version branch/a new branch/it depends on the feature) cassandra-5.1 now, on latest GA once we release one under that contract 3.) If a new branch for backports is created, what existing major release branch should it be based on? (4.1/5.0/trunk, which is currently on track to be a 6.0) cassandra-5.0 4.) If a new branch is introduced, what should be the fate of cassandra-4.0? (make unsupported when the new branch releases/keep until 6.0 releases) EOL when new branch is cut, but don't EOL 4.1 when 6.0 hits. Get to new cadence on next backport line (see above). On Tue, Oct 14, 2025, at 3:23 PM, Caleb Rackliffe wrote: I'll go ahead and cast a ballot along the lines of what I posted earlier: > 1.) Should we have a mechanism to backport CEP-37, Java 21, and things like > them, that do not introduce messaging or on-disk version changes? Yes > 2.) Where should those backports happen? (An existing major version branch/a > new branch/it depends on the feature) Either cassandra-5.0 or a new cassandra-5.1 (based on the former, equivalent for upgrade purposes). > 3.) If a new branch for backports is created, what existing major release > branch should it be based on? (4.1/5.0/trunk, which is currently on track to > be a 6.0) cassandra-5.0 (Anything earlier encourages stagnation.) > 4.) If a new branch is introduced, what should be the fate of cassandra-4.0? > (make unsupported when the new branch releases/keep until 6.0 releases) cassandra-4.0 becomes unsupported when cassandra-5.1 (if we go that direction) is released On Tue, Oct 14, 2025 at 1:23 PM Jaydeep Chovatia <[email protected]<mailto:[email protected]>> wrote: >Regarding the JDK 21 support backport mentioned in the thread, is it really >the case even after we voted to backport support for new JDK versions here?: >https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9<https://urldefense.com/v3/__https:/lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9__;!!Nhn8V6BzJA!VLMnYnrkQuP2_rbDEBHcD_-N84xP0B29YQKfxs1R0qTdk4HOXI6V8-9kd1h46kqW93TvG6thn1oCezjWKSlJvhuCBg$> > ? First, thank you for bringing the historical JDK ML thread—I respect and appreciate the context and decisions captured in the JDK ML thread. On JDK version support, could we take a particularly careful, data-informed approach? My (possibly incomplete) understanding is that most organizations have moved beyond JDK 11, with Cassandra being an exception. That can put operators in a difficult position internally and, at times, create perception issues for Cassandra—e.g., “if most of our stack has moved off JDK 11, why can’t Cassandra?” This is precisely the kind of discussion we need to have when deciding whether to backport any features to stable GA releases or not. Jaydeep On Tue, Oct 14, 2025 at 7:54 AM Dmitry Konstantinov <[email protected]<mailto:[email protected]>> wrote: Regarding the JDK 21 support backport mentioned in the thread, is it really the case even after we voted to backport support for new JDK versions here?: https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9<https://urldefense.com/v3/__https:/lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9__;!!Nhn8V6BzJA!VLMnYnrkQuP2_rbDEBHcD_-N84xP0B29YQKfxs1R0qTdk4HOXI6V8-9kd1h46kqW93TvG6thn1oCezjWKSlJvhuCBg$> ? On Tue, 14 Oct 2025 at 02:51, Jaydeep Chovatia <[email protected]<mailto:[email protected]>> wrote: >@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. Accord: I had an opportunity to review Accord briefly, and based on my understanding, this feature appears to be backward compatible during upgrades. I also have a reasonable level of confidence in its rollback capabilities, as this aspect was discussed to some extent in the “CEP-15 Update” mailing list thread. TCM: While I haven’t yet done an in-depth exploration of all its internals, after reviewing the CEP-21 proposal and our informal discussions during Community Over Code, my current impression is that rolling back from 5.1 to 5.0 after enabling TCM might be either highly complex or not feasible. Of course, I could be mistaken here. I really appreciate your clarification that rollback is fully supported and possible. Given that, it might be very valuable to document a detailed rollback plan (if none exists), corresponding rollback test cases (if none exists), and an [UPDATE] thread to help dispel the common perception that TCM lacks backward compatibility. Jaydeep On Mon, Oct 13, 2025 at 2:04 AM Alex Petrov <[email protected]<mailto:[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]<mailto:[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]<mailto:[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 -- Dmitry Konstantinov
