Totally in support of this idea. As we know, CEP-37 has already been merged into the trunk. However, many individuals who are not on the trunk have been using the CEP-37 work on 4.1. Therefore, I have been maintaining a private fork ( https://github.com/jaydeepkumar1984/cassandra/tree/auto_repair_v2_on_4_1), which is quite painful to manage. I have more 4.1 users inquiring about using this, as they are now aware that the CEP-37 4.1 work is already in use by Cassandra operators and is pretty stable, and they are already on 4.1. So more and more folks are going to rely on my private fork, which is not a great idea either.
I am in favor of officially supporting these features backport. Of course, we collectively vote on which features to backport and which ones not to. Jaydeep On Mon, Oct 6, 2025 at 11:35 AM Isaac Reath <[email protected]> wrote: > I’m in favor of this idea for all of the reasons Josh mentioned and I’m > happy to help out with the curation and maintenance. Consolidating these > efforts seems like a clear win to anyone who is already managing their own > fork of backports. > > A couple of questions that come to mind: > > 1) What is the inclusion criteria for a patch to get backported? > > 2) What does the lifecycle of this branch look like? If we use the example > of a cassandra-5.1 branch, what happens to this branch after 6.0 is GA? I > think there should be some grace period after the next version is cut where > this branch is still active, but we probably don't need as long of a > support model as the "main" (i.e. 4.0, 4.1, 5.0, 6.0) releases. > > > On Mon, Oct 6, 2025 at 1:39 PM Rahul Singh (ANANT) <[email protected]> > wrote: > >> Makes sense. Does this become "LTS" ? or is this something else. >> >> >> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote: >> >>> On Mon, Oct 06, 2025 at 04:03 PM 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 >>> >> >> >>
