What about this: do a proper 5.1 branch with everything (pipelines, release ...) but put there only Java 21 support and CEP-37?
Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 intact, 5.1 would be a branch we try this new model in, learn the lessons from it. When we support Java 21 and CEP-37 as only two changes and nothing else, it will already address Java 21 / unsupported Java 17 concerns and it would bring a lot of relief to people trying to transition to 6.0 eventually and they would have some time to prepare for that. Then, in 6.0, TCM / Accord would be production ready waiting for them to migrate to, while they would already be on Java 21 + repairs. So for a while we would have 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be 5.0 -> 5.1 -> 6.0 -> trunk Then we can do 6.1 branch and we will have some experience of what worked / did not and we will be more ready to backport more or we will just abandon this altogether. My idea is to just do something quick yet already beneficial. If we backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth, nothing new will be there to cause any friction. As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 -> 5.1 would be very easy, in majority of cases just clean merges up. The only overhead is CI but we have pre-ci too which we can leverage so ... I would be more open to this if we agreed that the scope of the backporting on this initial pilot will be limited to a minimum of features and nothing else. Then we can just reflect on what we did. On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa <[email protected]> wrote: > > > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <[email protected]> wrote: > > > > To respond to some of the other points and throw my perspective into the > mix: > > > >> Release engineering for a branch is nearly a full-time job. > > While release management is a burden (and one we've had a hard time > resourcing for years), I don't see it as being nearly a full-time job per > branch. We also have contributors willing to step forward and take on this > extra work and plenty of opportunity for automation on both release > preparation and validation that would lower that burden further. > > > >> Unofficial branches will miss correctness and compatibility fixes > unless their maintenance is made a burden for all committers. > > Both proposals (backport to 5.0, support a 5.1 that accepts backport) > would be considered official during the pilot. Bugfixes that are 5.0 or > older would have 1 more branch they needed to apply to and merge through. > > > > I see the word unofficial used too many times. There’s no such thing as > unofficial. If it’s merged by committers and voted on for release by the > PMC, it’s official. If it’s not, it doesn’t belong in the ASF repos. > > > > >> – Backports branches don’t solve the “some people run forks” problem. > > I see this a bit differently; it doesn't "solve" the problem (I don't > personally see this as a problem to be solved fwiw), but it does bring > those forks much closer to upstream and move engineering effort that would > otherwise be on private forks into the public space benefiting everyone. > > I think you’ve seen at least a few reasons in this thread why the goal and > proposal may not align. What one team considers ready and low risk, another > team begs not to be included. I suspect if there was really, truly a shared > understanding of “this is back port ready, low risk, ready to run”, we > could just put it into the existing branches (with a “yes this is a > feature, but it’s a feature we all trust” discussion)? > > >
