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
