That is a good question. I do not mind having it either way. I was just writing that in the spirit of Jeff's email where enthusiast-driven and unofficial is not something to do. If we agree on that being relaxed I ultimately don't mind.
On Mon, Oct 13, 2025 at 9:18 PM Alex Petrov <[email protected]> wrote: > > > 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 > > >
