If there are already unofficial forks of things like “4.1 + auto-repair”, it’s hard to object too much to codifying them, as long as they don’t introduce new messaging versions or make upgrades to an “official” later release difficult. (I’m assuming we wouldn’t, for example, want a 4.1++ that couldn’t be updated to 5.0?) I like the idea generally as a lot of big users do their own forks with these backports anyway and the work already being done would be more shared. Realistically there would likely still be forks, just lighter weight forks. One risk is that some users may not be comfortable with everything getting backported - but if there is trust in the collective effort and people use it, it provides a new path to features in contrast to the longer release cycles.
What I've gotten from this proposal for the near future:
4.0, 4.1, 5.0 - keep on with bug/CVE fixes, very conservative improvements, and backports trunk - the pile of new big things until we branch approximately annually - includes JDK support updates for the current two LTS versions
NEW: 5.1 - continually adding backports in point releases. Just for a theoretical scenario: 5.1.0 includes bigger compaction improvements, security features now only in trunk, etc. Releases happen periodically and include additional backports. Fast forward to 5.1.3. Something comes along that we wouldn't normally backport to 4.0/4.1/5.0 - something like an auto-repair-level feature. We would say - hey everyone, this is the backport branch between stable and trunk. After some discussion or vetting process, auto-repair comes is released with 5.1.4 along with fixes.
Then when 6.0 comes out, there would be a 6.1 with a similar cadence of more aggressive backports? At that point the actively supported branches are 4.1, 5.0, 6.0, and 6.1? At that point what happens with 5.1? Is that no longer supported because presumably people on that branch would then move to trunk?
Is that how things would play out according to the proposal?
Thanks,
Jeremy
What I “hear” here - the difference between backporting patches to older branches and to this backport branch is that backport branch can get a big feature, which is technically higher risk but we will choose non-disruptive ones. So just branch in a fairly good shape? Are we going to produce artifacts indeed? (I second Francisco here) I am wondering, what is the signal of having the need for such a branch? Our current release cycle needs revision? (Of course that is independent activity of what we discuss here)
My guess is that the request for people to maintain such a branch means that this branch won’t be part of the merge strategy and it will be maintained completely separately by volunteers?
Anyone has some write up that can give us an example how that works for some of the other projects mentioned?
Thanks, Ekaterina
I have to admit I feel slow because I genuinely can’t tell what’s functionally different from this vs the existing strategy where we … selectively write patches for older versions when they’re low risk / high reward for safety and security
Setting aside some unspecified nuances you haven’t haven’t defined, what makes this different from the existing practice of apply selective patches to old releases so users on old builds have a long term stable release that gets correctness and security fixes without the risk of new features ?
> On Oct 6, 2025, at 9:04 AM, Josh McKenzie <[email protected]> wrote:
>
>
> Many large‑scale Cassandra users have had to maintain private feature back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on older branches. That duplication adds risk and pulls time away from upstream contributions which came up as a pain point in discussion at CoC this year.
>
> 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).
>
> Benefits include reduced duplicated effort, a safer middle ground between trunk and frozen GA releases, faster delivery of vetted features, and community energy going to this branch instead of duplicated on private forks.
>
> If you’re interested in helping curate or maintain this branch - or have thoughts on the idea - please reply and voice your thoughts.
>
> ~Josh
|
