> 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. >>>> >>>> >
