> 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. Meant to also say: or we'd just have to support multiple backport branches w/bugfixes for longer time, which I'm not keen on.
(sorry for the noise on-list) On Mon, Oct 6, 2025, at 9:34 PM, Josh McKenzie wrote: > 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 >>>>>>> >>>>>>> >>>>>>> >
