I'm trying to keep a running idea of what a voting sequence to terminate this thread might look like. Right now I've got something like:
1.) Should we have a mechanism to backport CEP-37, Java 21, and things like them, that do not introduce messaging or on-disk version changes? (Yes/No) 2.) Where should those backports happen? (An existing major version branch/a new branch/it depends on the feature) 3.) If a new branch for backports is created, what existing major release branch should it be based on? (4.1/5.0/trunk, which is currently on track to be a 6.0) The idea is to start w/ what looks less contentious and narrow. Thoughts? On Mon, Oct 13, 2025 at 3:46 PM Josh McKenzie <[email protected]> wrote: > 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)? > > > > > > > > >
