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]> 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 ? > > 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]> > 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 ? >> >> >> On Tue, 14 Oct 2025 at 02:51, Jaydeep Chovatia < >> [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]> 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 >>>> >>>> >>>> >> >> -- >> Dmitry Konstantinov >> >
