Stefan, Sam – your concerns are absolutely valid and have come up in various discussions.
Here's the reality though – many large operators of Cassandra are maintaining backports of various features. The proposal here is to try and allow these contributors to maintain them in the community instead of internally. This is a limited time pilot to see if this model could work. 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. Stefan — nobody is talking about “opening the floodgates” here. The expectation is that small, self contained features could be back ported on a case by case basis. Let’s engage on the criteria that makes sense. On the subject of avoiding backports and using it as a tool to “force” people to upgrade, I’d like to point out that if upgrades were easier we would not be having this discussion. The simple fact is that upgrades are not easy and they are riskier than maintaining backports hence we see this pattern. If the community gets together and makes upgrades easier we will likely not have a need for backports. My suggestion is to engage with “how” this pilot would look like to shape it. It is a limited time experiment that might benefit the community. A number of contributors have shown interest so ideally we should be open to trying it out. > On Wed, Oct 8, 2025 at 12:12 AM Sam Tunnicliffe <[email protected]> wrote: > 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 > >
