I'd like to clarify 2 things – 1. Feature flags are an industry best practice for software development and should be practiced irrespective of which branch your code goes into.
2. Volunteers, regardless of their formal role on the project, should raise their hands to help with backports and release. We will figure out how to make it work within ASF's guidelines if you don't have a formal role on the project. Raising your hand lets us gauge the level of interest of the community in participating and therefore the success of the pilot. Thanks, Dinesh On Sat, Oct 11, 2025 at 9:59 AM Josh McKenzie <[email protected]> wrote: > I’d like to volunteer myself to become a release manager and help current > folks with that burden, if that is possible. > > That's great Bernardo. I'll step up and do the same. > > On Sat, Oct 11, 2025, at 12:42 PM, Bernardo Botella wrote: > > 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 <[email protected]> > 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 <[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. > > > >
