Re: [DISCUSS] Pilot program of an officially supported backport branch

[Bernardo Botella]

Great discussion everyone! I think we are moving in the right direction in shaping the process for these backports. My two cents: - Agreed with Francisco to only backport things that can be feature flagged. This is actually something we could be more strict about when adding more features. Maybe including a section on the CEP template would at least force us to have conversations about feature flagging and come up with strong reasons if we decide not to have flagging support? - I would also like to comment on one of the concerns raised by Stefan. Releases are not straight forward, and there are very few people doing them. The official release process states that only PMC members can finalize a release (https://cassandra.apache.org/_/development/release_process.html). I’ve been through half of that pain with the release of Analytics library 0.1.0, but it still had to go through one of the current release managers. As Stefan mentions, this initiative will only add burden to that process. I’d like to volunteer myself to become a release manager and help current folks with that burden, if that is possible. Cheers, Bernardo El oct 11, 2025, a las 4:47 a. m., Josh McKenzie <jmcken...@apache.org> escribió:  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 <patrickclee0...@gmail.com> 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: Wait for the official release. Build a temporary solution, knowing it’s short-lived. 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.