I'll take a crack at those questions Dinesh: > 1. What branch would be designated as a backports branch? A new branch ( `cassandra-5.1` ) should be created. While reusing `cassandra-5.0` reduces overhead, changing the identity of a GA release mid-lifecycle risks breaking user trust (Isaac's point holds as foundational to me). We have no way of knowing how many operators rely on 5.0’s stability contract.
> 2. What are the tradeoffs of reusing an existing vs new branch? *Reusing 5.0 (existing):* *- Pros:* Lower maintenance burden (fewer merges, fewer releases, less CI). *- Cons:* Violates the stability contract we put out for a GA release; erodes trust; risks destabilizing a widely deployed branch. *New branch (5.1):* *- Pros:* Preserves 5.0 as a true GA; creates clear separation between stable and community-backported features; aligns with OSS best practice / prior art - *Cons:* Adds maintenance overhead (merges, CI, releases); lifecycle ambiguity (when does it EOL?); higher initial setup cost. > 3. What would releases look like including release cadence? "5.1.0-beta", "5.1.0-backport", "5.1.0-community"; some flag to denote "not regular GA". Cadence: No fixed schedule (same as current GA). Reactive to feature merge or volume of smaller improvements, critical bugfixes, etc. > 4. What would be the success criteria of this pilot? - Increased community engagement (features backported in, releases cut); draw down of private forks - More contributors stepping up as release managers to maintain this branch - Multiple non-trivial production deployments using backport branch - Acceptable stability and trust in the backport branch releases > 5. What is the proposed time duration of the pilot? 12 months, with quarterly [DISCUSS] retro check-ins on dev@. If successful, we should consider evolving the model to: the latest GA release may accept community-approved backports. Only after proving the process works outside the GA branch first and only if we can signal this at the initial cut of the release. On Thu, Oct 9, 2025, at 5:05 PM, Dinesh Joshi wrote: > 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. >>>
