What remains unclear to me even after reading entire thread is upgrade and downgrade paths. It is extremely complicated to keep our current upgrade and downgrade paths working, and we have only gotten to a point where we have them well tested [1].
Between system schema changes (which most major features include), file format changes, messaging and client protocol changes, plus things like storage compatibility mode, people may get stranded on the branch with potentially complex migration paths. How are you going to ensure people can actually migrate between branches, and switch back to mainline if/when needed? Will this also impose extra effort on active maintainers / developers, where they will be required to develop a migration patch for some specific, potentially never deployed, combination of features? [1] https://issues.apache.org/jira/browse/CASSANDRA-14937 On Mon, Oct 6, 2025, at 6:03 PM, Josh McKenzie 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
