> 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)? I don't think we've tested this enough to know. We've drawn a hard line in the sand of "no backports of improvements or new features" as one of our many efforts at stabilizing the database; I haven't seen anyone make a strong argument against back-porting JDK21 support or CEP-37 for instance. So we haven't had these debates in a structured fashion yet; you might be right, but there may be ways we can mitigate that and move that needle.
My personal .02: I'd be comfortable with us allowing select backports to GA branches if we had some clear community consensus on the dev ML. I don't think it'd destabilize the DB if we were judicious about what we chose, and I believe on the whole users would prefer that balance vs. multi-year waits for new releases, new functionality, and all the qualification burden that comes from how "fat" our releases are. If the requirements were clear and agreed upon, something like: 1. Someone must be running it in prod on >= N clusters for >= M time (TBD) and vouch for their experience with it 2. Must be disabled by default / feature flagged 3. Must be able to easily and gracefully disable the feature w/out breaking your cluster, taking downtime, or otherwise impacting prod 4. Must be agreed upon by majority of PMC roll-called quorum on dev [DISCUSS] / [VOTE] thread for feature 5. Must be clearly and thoroughly documented (user, operator, dev docs in code-base and on website) I'd personally be happy with that. (I like your "cassandra-5.1, only add those 2 features" idea too Stefan but feel like there's value in exploring the "why don't we backport to GA?" question a bit further in isolation) On Mon, Oct 13, 2025, at 2: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)? >>
