I second Štefan's concerns here. The proposal reduces the incentive to upgrade or even test trunk, meaning that the things users want to avoid (features etc, but also just refactorings/re-implementations) because they are as-yet "untrusted" or "unqualified" remain that way for longer. This feels pretty antithetical to the direction we've been aiming to travel in, toward more regular release cycles.
> On 8 Oct 2025, at 06:41, Štefan Miklošovič <[email protected]> wrote: > > This is indeed an interesting idea but please let me share my point of view > and somehow different opinion on that. > > I share the questions with Jeff and Jeremiah a lot. I see it similarly and > they got the point. > > Before 5.0 was out, we had quite a situation where we officially had to take > care of 3.0, 3.11, 4.0 and 4.1 at the same time. If a bug was found, we had > to patch 5 branches at once (trunk as well). That meant 5 CI jobs. The > patching was an endeavour spanning multiple days, realistically. Once 5.0 got > out, we officially discontinued 3.0 and 3.11. But what I have been > experiencing was that this information about not supporting 3.0 / 3.11 was > spreading very slowly among people / customers and I / we had to repeatedly > explain to everybody that yes, 3.0 and 3.11 and done. What are they? Done? > Yes, done. 3.0 and 3.11 are finished. Finished you say? That means no > patches? Yes, no patches. Aha right ... For real? ... you got it. People had > to internalize that it is just not going to happen. > > When we "open the flood gates" then the existence of a backporting branch > will be the justification of anything they want to see there because they do > not want to upgrade. Instead of us working towards a more smooth upgrade we > are burying ourselves with older stuff. That slows adoption of new majors a > lot. People will not be forced to, there will be way less incentive to do > that when all the important goodies are backported anyway. > > I see that "the backports would be non-disruptive but potentially higher > risk". I do not completely understand what this means in practice. Let's say > CEP-37. Is that disruptive or not? What's the definition of that? To me, > correct me if I am wrong, is that something is disruptive if I just can not > turn it off even if I do not want to use it. Does one _have to_ use CEP-37 > when it is backported? No. They can just turn it off. So what is exactly the > risk of introducing it to e.g. 5.0.x ? > > Also, how are upgrades done? People are going to upgrade from 5.0.x to 5.1 > and then it will be possible to upgrade to 6.0 from 5.1? This would need us > to make the pipelines, incorporate this new path into upgrade tests and so on > ... a lot of work. > > I think that the current policy - "only bug fixes to older branches" might be > relaxed a bit instead and leverage already existing upgrade paths and > infrastructure to test it all instead of creating brand new branches we need > to take care of. > > Regards > > On Mon, Oct 6, 2025 at 6:04 PM Josh McKenzie <[email protected]> wrote: > Many large‑scale Cassandra users have had to maintain private feature > back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on > older branches. That duplication adds risk and pulls time away from upstream > contributions which came up as a pain point in discussion at CoC this year. > > The proposal we came up with: an official, community‑maintained backport > branch (e.g. cassandra‑5.1) built on the current GA release that we pilot for > a year and then decide if we want to make it official. The branch would > selectively accept non‑disruptive improvements that meet criteria we define > together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop, Kafka, > Linux kernel, etc). > > Benefits include reduced duplicated effort, a safer middle ground between > trunk and frozen GA releases, faster delivery of vetted features, and > community energy going to this branch instead of duplicated on private forks. > > If you’re interested in helping curate or maintain this branch - or have > thoughts on the idea - please reply and voice your thoughts. > > ~Josh
