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]> 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]> 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 >
