To respond to some of the other points and throw my perspective into the mix:
> Release engineering for a branch is nearly a full-time job. While release management is a burden (and one we've had a hard time resourcing for years), I don't see it as being nearly a full-time job per branch. We also have contributors willing to step forward and take on this extra work and plenty of opportunity for automation on both release preparation and validation that would lower that burden further. > Unofficial branches will miss correctness and compatibility fixes unless > their maintenance is made a burden for all committers. Both proposals (backport to 5.0, support a 5.1 that accepts backport) would be considered official during the pilot. Bugfixes that are 5.0 or older would have 1 more branch they needed to apply to and merge through. > – The upgrade matrix becomes more complicated. As features are backported... > these upgrade paths will be untested and unexercised. I agree the matrix would become more complicated but disagree that they would be untested and unexercised. I also think the marginal increase in complexity is worth taking on for the expected benefits. For example, with the "cassandra-5.1-backport" branch, we could support: • 4.1-5.0 • 5.0-6.0 • (new) 5.0-5.1-6.0 This would add 2 new paths to test and add one backport-branch-specific constraint (must go through 5.0 to get to 5.1). Any protocol changes in the backport branch would need to be validated *from *5.0 and *to *6.0, but otherwise not increase the surface area of breakage. Those types of changes would already need to be verified in the current status quo in the 5.0-6.0 path; introducing a branch in the middle that received a backport would involve validating that same functional change from 5.0-5.1 as from 5.0-6.0 prior, just in whatever differing context might be on that branch. > – There’s an assumption in this thread that backports are easy to pick up. I see this discussion as an exploration on how skilled contributors and committers can deduplicate their work on private forks, bring those forks closer to upstream, and make certain new features available to end users earlier. I haven't read anything as implying backporting is easy. > – Backports branches don’t solve the “some people run forks” problem. I see this a bit differently; it doesn't "solve" the problem (I don't personally see this as a problem to be solved fwiw), but it does bring those forks much closer to upstream and move engineering effort that would otherwise be on private forks into the public space benefiting everyone. > – Backports branches don’t solve the user community adoption problem either, > unless we’re also publishing per-OS packages, Maven artifacts, etc. I agree with you that we have a "time to new release" adoption problem broadly but I don't see this thread as attempting to address that; do we think providing a middle-ground release between frozen GA and feature-dense higher risk trunk would worsen adoption? --- I think a follow-up discussion about how we can enable and encourage users to test trunk or run releases cut from it (alphas cut monthly or quarterly) would be a great use of our time and energy. I also think it would be valuable to have a follow up discussion about how we can change our engineering practices to make GA releases less disruptive for users to transition onto, allow users to incrementally validate new optional features, and roll back to older releases with confidence in the event of defects (see prior email). On Sun, Oct 12, 2025, at 12:03 PM, [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
