> (from Josh) If the fear is that a backport branch is going to entrench users > prevent them from qualifying 6.0, that's something we can and should hash > out.
While I do not think this is the only argument (Scott has mentioned many very important points in email from Oct 12), I do not think this one should be overlooked or silenced in the name of brevity. This is an important aspect: community fragmentation and working together on new releases. I don't mind having JDK fixes back ported to all branches (which was already agreed and supported unanimously). But I think we should work together on making new release easy to roll out for everyone rather than backport (potentially) everything except two major features. On Wed, Oct 15, 2025, at 3:55 PM, Josh McKenzie wrote: >> severely preventing 6.0 from broader adoption > If we believe people are maintaining backport branches because there's > specific reluctance to qualify 6.0 (or other releases like 5.0 for example), > maybe we need to have another [DISCUSS] thread on that topic. My hope (and > intuition) was and is that it'd be simpler to meet these contributors where > they are and where they're asking to contribute energy and effort to the > project in a way that'd deduplicate work and bring benefit to the community. > > If the fear is that a backport branch is going to entrench users prevent them > from qualifying 6.0, that's something we can and should hash out. But on > another thread please, since this one is already *long*. :) > > On Wed, Oct 15, 2025, at 8:24 AM, Miklosovic, Stefan via dev wrote: >> 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]> 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]> >>>> 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]> 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 >> >
