Thanks Josh, I strongly support this proposal. I think having a community-maintained backport branch like cassandra-5.1 would greatly reduce duplicated efforts and make it much easier for operators to adopt important improvements without maintaining separate forks. This can really help align the community’s energy and accelerate the adoption of stable, well-tested features.
I do have a couple of questions to better understand how this would work in practice: 1. What will be the *criteria to determine whether a feature is considered “non-disruptive”* and eligible for inclusion? 2. How will the *backport process* be initiated? For instance, should it be started by the contributor of the original feature, or can anyone interested in a particular feature from trunk propose a backport to this branch? Really excited to see this discussion moving forward — I think this could meaningfully improve how we maintain and evolve Cassandra between major releases. Best, Runtian On Tue, Oct 7, 2025 at 9:48 AM Francisco Guerrero <[email protected]> wrote: > This is a great idea, but like others I do have some additional questions > about this: > > 1. Are we going to be producing artifacts from these branches? > 2. How many branches are we planning on keeping? Is it one per branch we > "officially" support? > > Best, > - Francisco > > On 2025/10/06 16:03:38 Josh McKenzie 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 >
