I was basing my understanding on the original proposal: > The proposal we came up with: an official, community‑maintained backport > branch (e.g. cassandra‑5.1) built on the current GA release that we pilot for > a year and then decide if we want to make it official. The branch would > selectively accept non‑disruptive improvements that meet criteria we define > together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop, Kafka, > Linux kernel, etc).
emphasis on: “built on current GA release” and “will selectively accept non disruptive improvements”. It was not clear to me that creating changes in this branch will create work in later branches, such as trunk. If my understanding is correct, cutting this branch will likely make it a mandatory version in an upgrade path from 4.0 which I think differs from the initial proposal. On Mon, Oct 13, 2025, at 9:48 PM, Jeremiah Jordan wrote: > I have always read this as the back porting of features and releases would be > done by some group of interested parties, but the branch itself would be an > official branch in the release branch merge path. Otherwise I don’t see is > much point. > > -Jeremiah > > On Mon, Oct 13, 2025 at 2:40 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)? >>>> > >>>> > >>>> >>>
