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 > On Oct 7, 2025, at 4:00 PM, Ekaterina Dimitrova <[email protected]> wrote: > > 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 > > > On Tue, 7 Oct 2025 at 4:53, Jeff Jirsa <[email protected] > <mailto:[email protected]>> wrote: >> 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] >> > <mailto:[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
