> 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.
This sounds like backport branches are going to create substantial burden for active maintainers. For most of the discussion it sounded more like a backport branch will be created and maintained by a select group of volunteers who want to help the community by making a small number of patches also available in other branches. This means it will not be on an active merge path (i.e., when merging something into 5.0, you skip the backport branches and go straight to 6.0), and all changes will be pulled there electively. Also, active maintainers will not have to reason through which backport branches there exist and which compatibility implications they impose. Has this changed over the course of the discussion? On Mon, Oct 13, 2025, at 4:02 PM, Josh McKenzie wrote: > 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 >
