Yeah, we didn't really get into guts of lifecycle. I could see "backport branch goes EOL when latest GA stabilizes" since then moving to a new backport branch should be low risk. It would leave users on the older backport branch stranded and force upgrades however; using the backport branch would be committing to more frequent updates to stay on a supported branch.
> 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? This doesn't ruffle my feathers. On Mon, Oct 6, 2025, at 7:43 PM, Jeremiah Jordan wrote: > 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 >>>>>> >>>>>> >>>>>>
