> 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. >>>>> >>
