Jeff has a branch. He proposes back porting a feature he wrote and runs on 5.0 to 4.0-something. Jeff does the work. Jeff attests that the branch is used a lot and he trusts it. Fine.
What happens to that branch next? If Patrick also does the same, does it go to the same branch? Or a different branch? If Alex has a security fix, is he obligated to fix Jeff’s branch? Patrick’s branch? Every branch? Making a branch isn’t a big deal. Releasing it is. Maintaining it is. What’s the release and maintenance story of the “for the benefit of everyone” branch? > On Oct 13, 2025, at 1:22 PM, Patrick McFadin <[email protected]> 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] > <mailto:[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] >> <mailto:[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] >>>> <mailto:[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] >>>>> <mailto:[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] >>>>> > <mailto:[email protected]>> wrote: >>>>> > >>>>> > >>>>> > >>>>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <[email protected] >>>>> > > <mailto:[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)? >>>>> > >>>>> > >>>>> >>>>
