> Jeff has a branch... The proposal is we have a shared "cassandra-N-backport" branch that we collectively backport things to. Bugfixes also merge to it.
The upgrade path is something we'll need to discuss; we could selectively enforce a requirement that upgrading through the backport branch cannot be required and architect our changes and testing accordingly. re: the verbiage on the original email: on re-read it's definitely ambiguous. I meant to refer to the "backport branch official release process" as a durable official process we do going forward (i.e. promotion from pilot to official), not that the branch itself would not be official. Words are hard. =/ On Mon, Oct 13, 2025, at 4:38 PM, Josh McKenzie wrote: > 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)? >>>>>> > >>>>>> > >>>>>> >>>>> >
