I'd add: 3. Bugfixes get merged into this branch and it's part of our merge path
So yes: other contributors doing a bugfix on an older branch would need to merge it through the backport branch. In theory the divergence from whatever its base branch is should be minimal. If we EOL'ed 4.0 with release of a backport branch we'd still need to maintain a net new branch (in terms of merging bugfixes) if 7.0 fast follows. On Mon, Oct 13, 2025, at 4:22 PM, Patrick McFadin wrote: > What a thread, but a good one. > I'm going to rewind to the very first email Josh sent. At Community over > Code, I joking(not joking) had a slide that said "Somebody in 2035 will ask > for a feature to be backported to 3.x" I want to make sure I got what you > were proposing Josh, because the conversation has been sub-threading. > > 1. Create a branch designated explicitly as a backport. You were calling it > 5.1, but it could easily exist in 4.x > 2. Somebody wants to backport a feature, instead of doing it on > $INTERNAL_FORK, propose it on the ML, +1s and then the backport work is for > the benefit of everyone in the Cassandra community. > > Everything else seems like bikeshedding, but I could be wrong. Please correct > me. > > Patrick > > On Mon, Oct 13, 2025 at 12:57 PM Dinesh Joshi <[email protected]> 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)? >>>>> > >>>>> > >>>>> >>>>
