> 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
I was thinking about this a lot recently and I just feel uneasy about messing up with 5.0.x. I know I was proposing this myself but I do not have a problem changing my mind. I don't know ... it just feels wrong to do that. Java 21 into a _patch release_? A stable release should be just something I literally copy jars over and I am done. I am not completely sure the same level of trust might be put into backporting stuff etc. I know that it is more work but all things considered I think 5.1 with a strict limit on features is just the best way forward. I am not sure we have the luxury of exploring that, we can't make mistakes here, we have just one shot at this, basically. Really on the edge with this one. Really interesting topic indeed. On Mon, Oct 13, 2025 at 8:28 PM Josh McKenzie <[email protected]> wrote: > 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)? > > >
