How about we flip the problem statement. Let's first find out all the fundamental changes any operator would need. Once we all agree on the list, then we can find out the right way to support them, it might we just not create a new branch and backport on the official branch similar to how we do bug fixes.
Here is my list and opinion: - [Must have] Minimum JDK21 support on 4.1 and higher - [Should have] CEP-37 on 4.1 or higher Of course, we should do a formal vote and then come up with a curated list. So, if the list is small enough, we might as well not go for a new fork; instead, just support the agreed list of items on the existing branch, say 4.1.12 with JDK21 support, 4.1.13 with CEP-37, and so on. That way, we serve two purposes: 1) Continue to support fundamental items for Cassandra to everybody, which helps smaller and larger operators, 2) Avoids extra fork, which reduces burden on committers, etc. Sure, we can argue that adding JDK21 + CEP-37 involves a lot more code changes, but we should only select features that are mostly not touching critical pieces, such as messaging structure, disk structure, isolated code, etc., so that reduces the risk when doing minor version upgrades. For the long run to avoid such backports, we should start a separate discussion on how to build more confidence in trunk and how we can speed up the Cassandra deployment from trunk by the majority at a much smaller cadence, say 6 months. So, we don't have to worry about backporting fundamental stuff in the future. Jaydeep On Fri, Oct 31, 2025 at 10:43 AM Josh McKenzie <[email protected]> wrote: > Nowadays, bug fixes go to four branches (4.0, 4.1, 5.0, trunk). Each > additional branch introduces significant overhead, > > For merging and CI, yes. Thanks for chiming in with your perspective! > > I also think this would be easier if we were to stop doing merge commits, > use github PR's to merge in code (pre-commit checks you say?), and have a > PR to apply to each branch for a change breaking up the --atomic > requirement blocker for multi-branch patches and reducing the toil there. > It's a lot easier to automate the creation and maintenance of that than it > is our current flow. > > Which I can cause a ruckus with on another [DISCUSS] thread. > > :D > > On Fri, Oct 31, 2025, at 1:39 PM, Josh McKenzie wrote: > > In fact, since JDK 25 is now the latest LTS release, *per our policy* we > should now prioritise moving trunk to 25 and adding support for LDK 25 to > 5.0 (and 4.1). > > I'd have JDK21 support merged already if I were working on that instead of > accidentally rabble-rousing with email threads. =/ > > I *think* we can get JDK21 support in to unblock 6.0 discussions and then > just incrementally add JDK25 as an incremental step peri or post 6.0 > qualification, backport ability to run it through all branches, and kind of > incrementally win here. > > The downside to doing that would be 6.0 LTS branch being constrained to > JDK21 language levels, but this would be a post 6.0 GA world where mostly > bugfixes would be going to that branch and we could push lang level to 25 > on trunk as soon as other GA was tested runtime with it. > > +1 on us just having a [DISCUSS] around a selective backport for CEP-37. > > I really do believe cadenced releases + alphas from trunk will give us > almost all the same benefits we're chasing with a backports branch w/out > adding another branch maintenance burden (merge path + CI). "Qualify a > release from backport branch" should be comparable to "Qualify a release > from an alpha branch" in terms of exposure to new features and disruption. > If we did a quarterly alpha that'd give people some flexibility on > checkpoints of where they wanted to take on qualifying and integrating a > release on their fleet. > > On Fri, Oct 31, 2025, at 9:11 AM, Aleksey Yeshchenko wrote: > > Regarding JDK 21: it is *already* our policy to backport new JDK LTS > support to all supported GA branches. > > We do not need to cut 5.1 for that. We are *expected* to add support for > JDK 21 to 5.0 once it’s landed in trunk: > > *[New LTS JDK Adoption]* > > - When a new JDK goes LTS, we prioritize: > > > - > - Moving trunk to build, run, pass CI, and support language level > of that JDK, dropping others > - Adding support to *run* on that JDK to all supported GA releases, > passing all CI using that JDK > > > (via > https://cwiki.apache.org/confluence/display/CASSANDRA/JDK+Version+Support+Policy > ) > > In fact, since JDK 25 is now the latest LTS release, *per our policy* we > should now prioritise moving trunk to 25 and adding support for LDK 25 to > 5.0 (and 4.1). > > That leaves just CEP-37 as something folks seem to want to backport. If we > do that, I would prefer the backport land in 5.0 rather than an in-between > 5.1 branch with just the CEP-37 in it (which seems like overkill to me). > > On 30 Oct 2025, at 16:32, Štefan Miklošovič <[email protected]> > wrote: > > I would just reiterate what I wrote here (1). > > While we are not running forks as already described / explained above, > that does not mean that just because of that I will be against some > kind of a solution which makes people's life easier. Sure, have your > branch if you want and if you have people to release it and so on ... > Who am I to forbid that ... > > The response of Jaydeep in this thread is very reasonable and > resonates with me the most, everybody in this thread is from a company > who has capacity to have forks and manage them etc. but what about the > folks who would just have to run this and they are genuinely afraid / > stuck? We should look beyond our immediate interests here, IMHO. > > But on the other hand, and that is what I think I did not get a > satisfactory answer to, is what will be the scope of that branch you > are proposing to create? I want to meet you somewhere in the middle, > sure make 5.1, make it supporting Java 21 and sure put CEP-37 there, > but only that! > > I think that if we had just these two things in plus bug fixes from > 5.0 that would make people in general way more acceptable to this > idea. But so far it seems to me that once we create 5.1, over time it > will be just a branch to backport this and that and I don't want that > for the sake of some basic predicatiblity and I do not want myself to > suddenly find deep down in backport business. > > Just make 5.1 to fix the pain points Jaydeep was talking about if you > want but please let's keep it somehow manageable. > > If somebody strongly opposes the creation of any additional branches, > that is fine and that is their opinion I respect. I just want to say > that I will not be the one who will vehemently and ultimately block it > AS LONG AS we will keep it strongly about Java 21 + CEP 37 + bugfixes > from 5.0. > > (1) https://lists.apache.org/thread/mgb8y66wdwq0w5s6hl10qmxd9fbwswmd > > On Thu, Oct 30, 2025 at 4:34 PM Aleksey Yeshchenko <[email protected]> > wrote: > > > Overall I’m strongly opposed to any solution which introduces additional > branches. > > OTOH I have no problem at all with backporting JDK 21 support to an > existing branch where viable. > > On 30 Oct 2025, at 15:23, Aleksey Yeshchenko <[email protected]> wrote: > > The mandatory extra work would come from having additional branches on the > merge path up. In addition to actually merging the code, it’s the hassle of > getting green CI results for the backport branches, delaying the merge. > > Or these branches are skipped on the regular merge path and it becomes the > job of the branch-backport volunteers - now responsible for every single > commit that lands in that branch, including the future-ports of bug fixes. > > On 24 Oct 2025, at 07:49, Dinesh Joshi <[email protected]> wrote: > > Committers are not required to backport their features to these branches > so I don't see this as 'mandatory' for all committers. Please elaborate if > there are aspects of maintenance that I've missed. > > > > >
