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