I think this is an interesting idea. I am also wondering what you think the life cycle looks like for such a branch once 6.0 is released? Does it continue getting backports from the new trunk? Do we start a “6.1” branch and stop maintaining this “5.1” branch? Do we maintain both 5.1 and 6.1?
A different idea. For tickets that a large group of people want in 5.0, does it make more sense to vote to bring those things into the main 5.0 branch? Rather than adding yet another branch to the merge path/maintenance burden? I’m not against this. Just want to explore if there are other options to achieving the goal. -Jeremiah Jordan On Mon, Oct 6, 2025 at 5:14 PM Bernardo Botella < [email protected]> wrote: > I think this is a great idea (as you know Josh ;-) ) > > I would love to work on Constraints being back ported > > Regards, > Bernardo > > > On Oct 6, 2025, at 12:56 PM, Patrick Lee <[email protected]> > wrote: > > 100% in favor and how ever i can be involved here i'm game! I've been > involved with deciding to have our own internal fork for this purpose but > there is some hesitation for the same reason that Jaydeep says. I did > early on backport CEP-37 for Cassandra 5 and was running tests before it > was merged into trunk but we didn't go beyond that. We have a lot of 4.0 > and 5.0 in our fleet as we basically overlooked 4.1. So having things like > CEP-37 in a 5..0 code base i'm all in! > > On Mon, Oct 6, 2025 at 1:42 PM Jaydeep Chovatia < > [email protected]> wrote: > >> 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 >>>>> >>>> >>>> >>>> >
