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
