Wanted to recenter this conversation on the proposal and summarize my understanding –
1. Our community wants a backports release and a stable release of cassandra. 2. Some operators would prefer to backports while others are ok waiting until the next major. 3. We are not talking about backporting all features only limited set of features in consultation with the broader community. 4. This is a limited time pilot. Advantages: 1. We satisfy broader community needs. 2. By keeping backports and stable releases separate, we isolate risks to backports branch & release. 3. Limited time experiment allows us to adjust this approach including sunsetting it if we determine that we don't serve the community's need or excessive burden on maintainers. 4. Allows broader participation and growing the community. Concerns: 1. Maintenance burden on existing maintainers - more releases, more artifacts, more targets to patch & merge. 2. Lack of sufficient release managers, maintainers, etc. Mitigations: Maintenance burden & lack of sufficient release managers – this is a broader pre-existing issue which will be exacerbated unless we get more people signed up for releases and maintaining. My expectation is that contributors who are enthusiastic about championing this proposal should commit to taking on that burden. I also expect that PMC members and Committers will sign up to support the contributors to make this successful. We will evaluate the success at the end of the pilot period and figure out the a way forward. On Aleksey's point about just broadening the backporting criteria, I honestly have mixed feelings about this approach. In the past there has been a fear of destabilizing a released, stable branch so we limited the patches to security fixes and critical bug fixes. I am sure those concerns do still exist. Once we run this pilot, we will have a better understanding of the adoption rate of backports release vs stable release. If the data suggests that most people are comfortable taking backports release, we can revisit the project's governance and broaden the criteria. I would really like to defer making this decision until then. If everybody is generally onboard with the proposal, we can start getting into the details of the logistics and I would suggest we circle back with more details which include - 1. What branch would be designated as a backports branch? 2. What are the tradeoffs of reusing an existing vs new branch? 3. What would releases look like including release cadence? 4. What would be the success criteria of this pilot? 5. What is the proposed time duration of the pilot? Thanks, Dinesh On Thu, Oct 9, 2025 at 9:29 AM Patrick Lee <[email protected]> wrote: > I wanted to share some thoughts from a user perspective on how we get >> features released sooner. >> >> When 5.0 was released, there were statements like *“5.1 will be released >> very soon with even more features.”* At conferences and presentations, >> we showcase all these new capabilities, which drives a lot of >> excitement—but it often takes a while before those features are available >> in a release. >> >> I really appreciate the stability of our releases and wouldn’t want to >> compromise that. Upgrading fleets takes time, and we don’t always jump on >> every new version immediately. That said, when I see features that help me, >> I adopt them quickly—at least for new deployments—to evaluate stability in >> our environment as we expand and upgrade. >> >> Right now, I’m working on handling repairs differently than before. With >> CEP-37 in truck, I’m questioning how long I should wait. Why spend time >> implementing something else if Cassandra will soon support this? If I have >> to wait until 6.0, I have no idea how long that will take. My options >> become: >> >> 1. Wait for the official release. >> 2. Build a temporary solution, knowing it’s short-lived. >> 3. Maintain an internal fork and backport the feature myself. >> >> At the moment, I’m in a better position to use an official release and >> report issues than maintain our own fork. Having access to the features I >> need gives me more incentive to upgrade, which makes adoption easier. >> >> Would introducing a 5.1 branch help get some new features out sooner? >> That would allow users like me to start taking advantage of them. Deciding >> when to move to 6.0 could then be part of the vote if additional features >> come along that need backporting. >> >> This whole discussion also makes me want to get more involved in the >> community. I’m not contributing code yet, but that’s definitely a goal for >> me. As I find more ways to share my time and experience, I’d like to be >> more vocal and engaged. It feels like a good way to ground myself and start >> giving back where I can. >> >
