I’m not sure where the word unofficial came from. The question is only if we merge every commit to it or no.
If every commit is merged to it, it’s not a “backport branch”, it’s just a regular release version, just created retrospectively, and should be presented as such. If it’s a regular release (5.1), and every commit that is merged into 5.0 will go to 5.1, it’s a different discussion: it will have to be added to future branches as a separate version, and maintained for upgrade paths from 4.0 upwards. On Mon, Oct 13, 2025, at 9:55 PM, Dinesh Joshi wrote: > The title of this thread is “[DISCUSS] Pilot program of an officially > supported backport branch” > > I want to draw attention to the word _official_. There is nothing unofficial > about what is being discussed here. I am not sure why is that word being > thrown around in the thread. > > To the PMCs and Committers on this project in this thread - we are talking > about our project’s governance and the OFFICIAL policy around backports. I > hope this clarifies what the goal of this thread and discussion is. > > There was a prior mentions about this being a branch where backported code > would live and will be untested. Let me clarify that we’re not talking about > just a branch. The project will create artifacts and release them. Having > code living in a repository without being released runs counter to ASF’s > principles. > > Thanks, > > Dinesh > > On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe <[email protected]> > wrote: >> This sort of has to be about something we’ll do officially as a project, or >> the original post is little more than asking what we think about a public >> fork, which (as bad as it would look for the project) nobody really needs >> approval to do anyway, right? >> >>> On Oct 13, 2025, at 2:28 PM, Alex Petrov <[email protected]> wrote: >>> >>> Thank you for the pointer but I did read it. >>> >>> My point is that this thread seems to have gone from “let’s create a branch >>> to electively pull changes into” to “we are retrospectively adding a 5.1 >>> branch somewhere between 5.0 and current trunk”, which I think is a >>> completely different discussion. >>> >>> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote: >>>> I am afraid something like an "enthusiast-driven branch" is not a >>>> thing. Please read the last email of Jeff, first section. >>>> >>>> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov <[email protected]> wrote: >>>> > >>>> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk >>>> > >>>> > Could you elaborate: I was under impression the new branch is going to >>>> > be maintained by a group of enthusiasts. Are we now considering making >>>> > this new branch in the upgrade path? This sounds rather different from >>>> > the original idea of having an officially supported back port branch. >>>> > >>>> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote: >>>> > >>>> > 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)? >>>> > >>>> > >>>> >>>
