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

This sort of has to be about something we’ll do officially as a project, or the original post is little more than asking what we think about a public fork, which (as bad as it would look for the project) nobody really needs approval to do anyway, right?On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:Thank you for the pointer but I did read it.My point is that this thread seems to have gone from “let’s create a branch to electively pull changes into” to “we are retrospectively adding a 5.1 branch somewhere between 5.0 and current trunk”, which I think is a completely different discussion.On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:I am afraid something like an "enthusiast-driven branch" is not athing. Please read the last email of Jeff, first section.On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:>> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk>> Could you elaborate: I was under impression the new branch is going to be maintained by a group of enthusiasts. Are we now considering making this new branch in the upgrade path? This sounds rather different from the original idea of having an officially supported back port branch.>> On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:>> What about this: do a proper 5.1 branch with everything (pipelines, release ...) but put there only Java 21 support and CEP-37?>> Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 intact, 5.1 would be a branch we try this new model in, learn the lessons from it. When we support Java 21 and CEP-37 as only two changes and nothing else, it will already address Java 21 / unsupported Java 17 concerns and it would bring a lot of relief to people trying to transition to 6.0 eventually and they would have some time to prepare for that. Then, in 6.0, TCM / Accord would be production ready waiting for them to migrate to, while they would already be on Java 21 + repairs.>> So for a while we would have>> 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk>> Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be>> 5.0 -> 5.1 -> 6.0 -> trunk>> Then we can do 6.1 branch and we will have some experience of what worked / did not and we will be more ready to backport more or we will just abandon this altogether.>> My idea is to just do something quick yet already beneficial. If we backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth, nothing new will be there to cause any friction.>> As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 -> 5.1 would be very easy, in majority of cases just clean merges up.>> The only overhead is CI but we have pre-ci too which we can leverage so ...>> I would be more open to this if we agreed that the scope of the backporting on this initial pilot will be limited to a minimum of features and nothing else. Then we can just reflect on what we did.>> On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote: > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  wrote:> >> > To respond to some of the other points and throw my perspective into the mix:> >> >> Release engineering for a branch is nearly a full-time job.> > While release management is a burden (and one we've had a hard time resourcing for years), I don't see it as being nearly a full-time job per branch. We also have contributors willing to step forward and take on this extra work and plenty of opportunity for automation on both release preparation and validation that would lower that burden further.> >> >> Unofficial branches will miss correctness and compatibility fixes unless their maintenance is made a burden for all committers.> > Both proposals (backport to 5.0, support a 5.1 that accepts backport) would be considered official during the pilot. Bugfixes that are 5.0 or older would have 1 more branch they needed to apply to and merge through.> >>> I see the word unofficial used too many times. There’s no such thing as unofficial. If it’s merged by committers and voted on for release by the PMC, it’s official. If it’s not, it doesn’t belong in the ASF repos.>> >> >> – Backports branches don’t solve the “some people run forks” problem.> > I see this a bit differently; it doesn't "solve" the problem (I don't personally see this as a problem to be solved fwiw), but it does bring those forks much closer to upstream and move engineering effort that would otherwise be on private forks into the public space benefiting everyone.>> I think you’ve seen at least a few reasons in this thread why the goal and proposal may not align. What one team considers ready and low risk, another team begs not to be included. I suspect if there was really, truly a shared understanding of “this is back port ready, low risk, ready to run”, we could just put it into the existing branches (with a “yes this is a feature, but it’s a feature we all trust” discussion)?>>

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

2025-10-18 Thread Francisco Guerrero

This is a great idea, but like others I do have some additional questions about 
this:

1. Are we going to be producing artifacts from these branches?
2. How many branches are we planning on keeping? Is it one per branch we 
"officially" support?

Best,
- Francisco

On 2025/10/06 16:03:38 Josh McKenzie wrote:
> Many large‑scale Cassandra users have had to maintain private feature 
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on 
> older branches. That duplication adds risk and pulls time away from upstream 
> contributions which came up as a pain point in discussion at CoC this year.
> 
> The proposal we came up with: an official, community‑maintained backport 
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot for 
> a year and then decide if we want to make it official. The branch would 
> selectively accept non‑disruptive improvements that meet criteria we define 
> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop, Kafka, 
> Linux kernel, etc).
> 
> Benefits include reduced duplicated effort, a safer middle ground between 
> trunk and frozen GA releases, faster delivery of vetted features, and 
> community energy going to this branch instead of duplicated on private forks.
> 
> If you’re interested in helping curate or maintain this branch - or have 
> thoughts on the idea - please reply and voice your thoughts.
> 
> ~Josh

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

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

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

I'll go ahead and cast a ballot along the lines of what I posted earlier:

> 1.) Should we have a mechanism to backport CEP-37, Java 21, and things
like them, that do not introduce messaging or on-disk version changes?

Yes

> 2.) Where should those backports happen? (An existing major version
branch/a new branch/it depends on the feature)

Either cassandra-5.0 or a new cassandra-5.1 (based on the former,
equivalent for upgrade purposes).

> 3.) If a new branch for backports is created, what existing major release
branch should it be based on? (4.1/5.0/trunk, which is currently on track
to be a 6.0)

cassandra-5.0 (Anything earlier encourages stagnation.)

> 4.) If a new branch is introduced, what should be the fate of
cassandra-4.0? (make unsupported when the new branch releases/keep until
6.0 releases)

cassandra-4.0 becomes unsupported when cassandra-5.1 (if we go that
direction) is released


On Tue, Oct 14, 2025 at 1:23 PM Jaydeep Chovatia 
wrote:

> >Regarding the JDK 21 support backport mentioned in the thread, is it
> really the case even after we voted to backport support for new JDK
> versions here?:
> https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 ?
>
> First, thank you for bringing the historical JDK ML thread—I respect and
> appreciate the context and decisions captured in the JDK ML thread.
>
> On JDK version support, could we take a particularly careful,
> data-informed approach? My (possibly incomplete) understanding is that most
> organizations have moved beyond JDK 11, with Cassandra being an exception.
> That can put operators in a difficult position internally and, at times,
> create perception issues for Cassandra—e.g., “if most of our stack has
> moved off JDK 11, why can’t Cassandra?” This is precisely the kind of
> discussion we need to have when deciding whether to backport any features
> to stable GA releases or not.
>
> Jaydeep
>
> On Tue, Oct 14, 2025 at 7:54 AM Dmitry Konstantinov 
> wrote:
>
>> Regarding the JDK 21 support backport mentioned in the thread, is it
>> really the case even after we voted to backport support for new JDK
>> versions here?:
>> https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 ?
>>
>>
>> On Tue, 14 Oct 2025 at 02:51, Jaydeep Chovatia <
>> [email protected]> wrote:
>>
>>> >@Jaydeep Chovatia, could you elaborate on this, since to my best
>>> knowledge there _is_ a straightforward rollback path for the features I
>>> am aware of. You can enable Accord transactions and later disable them, and
>>> you can also migrate back to Gossip from TCM. Both of these
>>> upgrade/downgrade paths are thoroughly tested. If there are other features
>>> that lack downgrade path, please mention them.
>>>
>>> *Accord: *I had an opportunity to review Accord briefly, and based on
>>> my understanding, this feature appears to be backward compatible during
>>> upgrades. I also have a reasonable level of confidence in its rollback
>>> capabilities, as this aspect was discussed to some extent in the “CEP-15
>>> Update” mailing list thread.
>>>
>>> *TCM:* While I haven’t yet done an in-depth exploration of all its
>>> internals, after reviewing the CEP-21 proposal and our informal discussions
>>> during Community Over Code, my current impression is that rolling back from
>>> 5.1 to 5.0 after enabling TCM might be either highly complex or not
>>> feasible. Of course, I could be mistaken here. I really appreciate your
>>> clarification that rollback is fully supported and possible. Given that, it
>>> might be very valuable to document a detailed rollback plan (if none
>>> exists), corresponding rollback test cases (if none exists), and an
>>> [UPDATE] thread to help dispel the common perception that TCM lacks
>>> backward compatibility.
>>>
>>> Jaydeep
>>>
>>>
>>> On Mon, Oct 13, 2025 at 2:04 AM Alex Petrov  wrote:
>>>
 > For instance, when upgrading to 5.1, a lack of a straightforward
 rollback path can make the process risky.

 @Jaydeep Chovatia, could you elaborate on this, since to my best
 knowledge there _is_ a straightforward rollback path for the features
 I am aware of. You can enable Accord transactions and later disable them,
 and you can also migrate back to Gossip from TCM. Both of these
 upgrade/downgrade paths are thoroughly tested. If there are other features
 that lack downgrade path, please mention them.

 On Sun, Oct 12, 2025, at 9:12 PM, Jaydeep Chovatia wrote:

 Here is my opinion.

 >– Unofficial branches will miss correctness and compatibility fixes
 unless their maintenance is made a burden for all committers. If not,
 they’ll be buggier and more prone to data loss than trunk.

 Typically, the backporting effort is handled by the author or co-author
 of a given CEP. As long as they are motivated to pursue the backport, I
 don’t anticipate this being a concern. In most cases, their motivation
 naturally comes from the fact that they

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

Here is my opinion.

>– Unofficial branches will miss correctness and compatibility fixes unless
their maintenance is made a burden for all committers. If not, they’ll be
buggier and more prone to data loss than trunk.

Typically, the backporting effort is handled by the author or co-author of
a given CEP. As long as they are motivated to pursue the backport, I don’t
anticipate this being a concern. In most cases, their motivation naturally
comes from the fact that they are themselves relying on or benefiting from
the backported version.

>– The upgrade matrix becomes more complicated. As features are backported,
any change affecting internode messaging, config properties, etc. becomes a
potential compatibility breakage on upgrade, and these upgrade paths will
be untested and unexercised.
>– There’s an assumption in this thread that backports are easy to pick up.
Backporting is often not straightforward and requires a high degree of
understanding of the surrounding context, integration points, and what’s
changed across branches.

As discussed earlier, we should conduct a formal vote on any proposed
backports and exercise caution with those that alter internal communication
mechanisms, Gossip protocols, or introduce backward incompatibilities.
Backports should meet a higher threshold—either by addressing fundamental
gaps in the database framework or by delivering substantial
reliability/efficiency improvements. For instance, CEP-37 and JDK 17/21 are
strong candidates for backporting: the former is essential to maintaining
data correctness in Cassandra, while the latter has become necessary as
much of the industry has already transitioned beyond JDK 11.

>– The proposal runs counter to the goal of “people running the database
and finding + fixing issues.” I happily run trunk, but I don’t want to be
the only one running trunk if others are committing changes to it.
Committing changes to trunk then backporting them to releases considered
“stable” doesn’t produce a more stable database.
>– Backports branches don’t solve the “some people run forks” problem.
>– Increasing the user community’s confidence in running new releases of
the database. A lot of people are reluctant to upgrade, but it’s so much
safer and easier than since the 2.x/3.x days. We want people to be
confident running new releases of the database, not clinging to a branch.
>– Deploying trunk and reporting back. Contributors of new features they’d
like to backport should deploy and operate trunk. It’s the best way to
establish confidence and makes Cassandra better for everybody.

I must acknowledge that the upgrade process has come a long way since the
2.x and 3.x versions, but there’s still room for improvement. For instance,
when upgrading to 5.1, a lack of a straightforward rollback path can make
the process risky. This limitation often slows modernization efforts, as
teams are understandably hesitant to proceed without a reliable fallback.
Many businesses around the world run critical workloads on Cassandra, and
an outage caused by an upgrade would ultimately fall on the decision
makers—making them cautious about taking such risks.
This concern is precisely why many decision makers prefer to backport
features (such as CEP-37, JDK 17/21) and operate on private forks rather
than upgrade to 5.1. This proposal aims to make their lives easier by
providing an official and coordinated path for backporting, rather than
leaving each operator to maintain their own fork. For example, support for
JDK 17 or 21 on version 4.1 is already a widespread need among operators.
We should certainly begin a new discussion on how to make our upgrade/new
versions process safer, so that, in the long run, the need for backporting
and similar discussions is eliminated.

>– Increasing release velocity. We do need to improve here and I’d be open
to 5.1.

I am not sure that’s the case. For most decision makers, the primary
concern isn’t velocity but safety. The key question they ask themselves is,
‘What is my fallback plan?’ If that plan appears uncertain or risky, they
are understandably hesitant to proceed with an upgrade.

Jaydeep

On Sun, Oct 12, 2025 at 9:04 AM  wrote:

> I don’t think we have consensus on this thread, but it feels like some are
> pushing forward as if we do (“If everybody is generally onboard with the
> proposal, we can start getting into the details of the logistics…,”
> followed by discussion of logistics).
>
> The thread also contains multiple different proposals: new feature
> backports branches, liberalizing feature backports to stable releases,
> cutting 5.1 now, or stay the course.
>
> I don’t support creation of new backports branches, but will keep my
> thoughts brief since there’s a lot of discussion:
>
> – The CI burden of existing branches is really high. Either new branches
> are treated as first-class and impose stability burdens on committers, or
> they fall into disrepair and are unsuitable for releases. Release
> engineering for a br

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

>@Jaydeep Chovatia, could you elaborate on this, since to my best knowledge 
>there
_is_ a straightforward rollback path for the features I am aware of. You
can enable Accord transactions and later disable them, and you can also
migrate back to Gossip from TCM. Both of these upgrade/downgrade paths are
thoroughly tested. If there are other features that lack downgrade path,
please mention them.

*Accord: *I had an opportunity to review Accord briefly, and based on my
understanding, this feature appears to be backward compatible during
upgrades. I also have a reasonable level of confidence in its rollback
capabilities, as this aspect was discussed to some extent in the “CEP-15
Update” mailing list thread.

*TCM:* While I haven’t yet done an in-depth exploration of all its
internals, after reviewing the CEP-21 proposal and our informal discussions
during Community Over Code, my current impression is that rolling back from
5.1 to 5.0 after enabling TCM might be either highly complex or not
feasible. Of course, I could be mistaken here. I really appreciate your
clarification that rollback is fully supported and possible. Given that, it
might be very valuable to document a detailed rollback plan (if none
exists), corresponding rollback test cases (if none exists), and an
[UPDATE] thread to help dispel the common perception that TCM lacks
backward compatibility.

Jaydeep


On Mon, Oct 13, 2025 at 2:04 AM Alex Petrov  wrote:

> > For instance, when upgrading to 5.1, a lack of a straightforward
> rollback path can make the process risky.
>
> @Jaydeep Chovatia, could you elaborate on this, since to my best knowledge 
> there
> _is_ a straightforward rollback path for the features I am aware of. You
> can enable Accord transactions and later disable them, and you can also
> migrate back to Gossip from TCM. Both of these upgrade/downgrade paths are
> thoroughly tested. If there are other features that lack downgrade path,
> please mention them.
>
> On Sun, Oct 12, 2025, at 9:12 PM, Jaydeep Chovatia wrote:
>
> Here is my opinion.
>
> >– Unofficial branches will miss correctness and compatibility fixes
> unless their maintenance is made a burden for all committers. If not,
> they’ll be buggier and more prone to data loss than trunk.
>
> Typically, the backporting effort is handled by the author or co-author of
> a given CEP. As long as they are motivated to pursue the backport, I don’t
> anticipate this being a concern. In most cases, their motivation naturally
> comes from the fact that they are themselves relying on or benefiting from
> the backported version.
>
> >– The upgrade matrix becomes more complicated. As features are
> backported, any change affecting internode messaging, config properties,
> etc. becomes a potential compatibility breakage on upgrade, and these
> upgrade paths will be untested and unexercised.
> >– There’s an assumption in this thread that backports are easy to pick
> up. Backporting is often not straightforward and requires a high degree of
> understanding of the surrounding context, integration points, and what’s
> changed across branches.
>
> As discussed earlier, we should conduct a formal vote on any proposed
> backports and exercise caution with those that alter internal communication
> mechanisms, Gossip protocols, or introduce backward incompatibilities.
> Backports should meet a higher threshold—either by addressing fundamental
> gaps in the database framework or by delivering substantial
> reliability/efficiency improvements. For instance, CEP-37 and JDK 17/21 are
> strong candidates for backporting: the former is essential to maintaining
> data correctness in Cassandra, while the latter has become necessary as
> much of the industry has already transitioned beyond JDK 11.
>
> >– The proposal runs counter to the goal of “people running the database
> and finding + fixing issues.” I happily run trunk, but I don’t want to be
> the only one running trunk if others are committing changes to it.
> Committing changes to trunk then backporting them to releases considered
> “stable” doesn’t produce a more stable database.
> >– Backports branches don’t solve the “some people run forks” problem.
> >– Increasing the user community’s confidence in running new releases of
> the database. A lot of people are reluctant to upgrade, but it’s so much
> safer and easier than since the 2.x/3.x days. We want people to be
> confident running new releases of the database, not clinging to a branch.
> >– Deploying trunk and reporting back. Contributors of new features they’d
> like to backport should deploy and operate trunk. It’s the best way to
> establish confidence and makes Cassandra better for everybody.
>
> I must acknowledge that the upgrade process has come a long way since the
> 2.x and 3.x versions, but there’s still room for improvement. For instance,
> when upgrading to 5.1, a lack of a straightforward rollback path can make
> the process risky. This limitation often slows modernization effor

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

2025-10-18 Thread Jeremiah Jordan

I have always read this as the back porting of features and releases would
be done by some group of interested parties, but the branch itself would be
an official branch in the release branch merge path.  Otherwise I don’t see
is much point.

-Jeremiah

On Mon, Oct 13, 2025 at 2:40 PM Caleb Rackliffe 
wrote:

> This sort of has to be about something we’ll do officially as a project,
> or the original post is little more than asking what we think about a
> public fork, which (as bad as it would look for the project) nobody really
> needs approval to do anyway, right?
>
> On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
>
> 
>
> Thank you for the pointer but I did read it.
>
> My point is that this thread seems to have gone from “let’s create a
> branch to electively pull changes into” to “we are retrospectively adding a
> 5.1 branch somewhere between 5.0 and current trunk”, which I think is a
> completely different discussion.
>
> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
>
> I am afraid something like an "enthusiast-driven branch" is not a
> thing. Please read the last email of Jeff, first section.
>
> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
> >
> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Could you elaborate: I was under impression the new branch is going to
> be maintained by a group of enthusiasts. Are we now considering making this
> new branch in the upgrade path? This sounds rather different from the
> original idea of having an officially supported back port branch.
> >
> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
> >
> > What about this: do a proper 5.1 branch with everything (pipelines,
> release ...) but put there only Java 21 support and CEP-37?
> >
> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0
> intact, 5.1 would be a branch we try this new model in, learn the lessons
> from it. When we support Java 21 and CEP-37 as only two changes and nothing
> else, it will already address Java 21 / unsupported Java 17 concerns and it
> would bring a lot of relief to people trying to transition to 6.0
> eventually and they would have some time to prepare for that. Then, in 6.0,
> TCM / Accord would be production ready waiting for them to migrate to,
> while they would already be on Java 21 + repairs.
> >
> > So for a while we would have
> >
> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
> >
> > 5.0 -> 5.1 -> 6.0 -> trunk
> >
> > Then we can do 6.1 branch and we will have some experience of what
> worked / did not and we will be more ready to backport more or we will just
> abandon this altogether.
> >
> > My idea is to just do something quick yet already beneficial. If we
> backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth,
> nothing new will be there to cause any friction.
> >
> > As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0
> -> 5.1 would be very easy, in majority of cases just clean merges up.
> >
> > The only overhead is CI but we have pre-ci too which we can leverage so
> ...
> >
> > I would be more open to this if we agreed that the scope of the
> backporting on this initial pilot will be limited to a minimum of features
> and nothing else. Then we can just reflect on what we did.
> >
> > On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
> >
> >
> >
> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie 
> wrote:
> > >
> > > To respond to some of the other points and throw my perspective into
> the mix:
> > >
> > >> Release engineering for a branch is nearly a full-time job.
> > > While release management is a burden (and one we've had a hard time
> resourcing for years), I don't see it as being nearly a full-time job per
> branch. We also have contributors willing to step forward and take on this
> extra work and plenty of opportunity for automation on both release
> preparation and validation that would lower that burden further.
> > >
> > >> Unofficial branches will miss correctness and compatibility fixes
> unless their maintenance is made a burden for all committers.
> > > Both proposals (backport to 5.0, support a 5.1 that accepts backport)
> would be considered official during the pilot. Bugfixes that are 5.0 or
> older would have 1 more branch they needed to apply to and merge through.
> > >
> >
> > I see the word unofficial used too many times. There’s no such thing as
> unofficial. If it’s merged by committers and voted on for release by the
> PMC, it’s official. If it’s not, it doesn’t belong in the ASF repos.
> >
> > >
> > >> – Backports branches don’t solve the “some people run forks” problem.
> > > I see this a bit differently; it doesn't "solve" the problem (I don't
> personally see this as a problem to be solved fwiw), but it does bring
> those forks much closer to upstream and move engineering effort that would
> otherwise be on private forks into the public space benefiting everyone.
> >
> >

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

Thanks for the discussion - it looks like we agree on the problem and the 
trade‑offs involved.

Maintaining an extra branch would add toil: we’d have to merge bug fixes, run 
CI (including upgrade tests), and extend the already lengthy upstream path. A 
simpler alternative is to relax our backport restrictions on GA branches.

What about the following idea: allow community-approved feature backports to 
**latest GA** (with a brief window allowing backports to 2 GA branches) and 
tier releases as follows:

*When a new release is cut:*
 • New release / Latest GA (6.0): stabilizing (backports accepted)
 • Middle GA (5.0): backports accepted
 • Oldest GA (4.1): stable
*When the new release stabilizes:*
 • Latest GA (6.0): backports accepted
 • Middle GA (5.0): stable
 • Oldest GA (4.1): stable
This approach gives users a clear choice - stable, backport‑enabled, or a 
temporary stabilizing branch - without adding CI overhead.

On Wed, Oct 8, 2025, at 5:42 AM, Štefan Miklošovič wrote:
> Hi Dinesh,
> 
> thanks for reassuring that this branch would be really just for crucial 
> functionality where benefits justify the backport. I would be more willing to 
> entertain that idea but I still think that once people see 5.1 is up they 
> will want to support their case and there will be a lot of pressure to 
> backport this and that. Not all CEPs / features will make it. We need to be 
> very selective. There will be a lot of "massaging" around what can go in and 
> what not and the expectations would need to be set from the very beginning 
> and followed.
> 
> However, I am not still quite sure how that would work in general, reading 
> Josh email here:
> 
> "The branch would selectively accept non‑disruptive improvements that meet 
> criteria we define together."
> 
> Once people are on 5.1, they will want to have all the bug fixes in there as 
> well. So instead of merging from 4.0 to 4.1, 5.0 and trunk, we will be doing 
> 4.0. 4.1, 5.0, 5.1 and trunk?
> 
> If the answer is yes, then we will have just another branch we need to fully 
> maintain.
> 
> If the answer is no, as in we will skip 5.1 on merges from 4.0 to trunk, then 
> I think this will be met with disappointment and questions as to why we are 
> not patching 5.1 as well.
> 
> Basically we go all in and maintain 5.1 with all the patches from lower 
> branches or we just maintain and backport important features but then ... who 
> is going to use it like that - without receiving bug fixes. 
> 
> 
> 
> On Wed, Oct 8, 2025 at 9:46 AM Dinesh Joshi  wrote:
>> Stefan, Sam – your concerns are absolutely valid and have come up in various 
>> discussions.
>> 
>> Here's the reality though – many large operators of Cassandra are 
>> maintaining backports of various features. The proposal here is to try and 
>> allow these contributors to maintain them in the community instead of 
>> internally. This is a limited time pilot to see if this model could work.
>> 
>>> When we "open the flood gates" then the existence of a backporting branch 
>>> will be the justification of anything they want to see there because they 
>>> do not want to upgrade.
>> 
>> Stefan — nobody is talking about “opening the floodgates” here. The 
>> expectation is that small, self contained features could be back ported on a 
>> case by case basis. Let’s engage on the criteria that makes sense.
>> 
>> On the subject of avoiding backports and using it as a tool to “force” 
>> people to upgrade, I’d like to point out that if upgrades were easier we 
>> would not be having this discussion. The simple fact is that upgrades are 
>> not easy and they are riskier than maintaining backports hence we see this 
>> pattern.
>> 
>> If the community gets together and makes upgrades easier we will likely not 
>> have a need for backports.
>> 
>> My suggestion is to engage with “how” this pilot would look like to shape 
>> it. It is a limited time experiment that might benefit the community. A 
>> number of contributors have shown interest so ideally we should be open to 
>> trying it out. 
>>> 
>> 
>> On Wed, Oct 8, 2025 at 12:12 AM Sam Tunnicliffe  wrote:
>>> I second Štefan's concerns here. The proposal reduces the incentive to 
>>> upgrade or even test trunk, meaning that the things users want to avoid 
>>> (features etc, but also just refactorings/re-implementations) because they 
>>> are as-yet "untrusted" or "unqualified" remain that way for longer. This 
>>> feels pretty antithetical to the direction we've been aiming to travel in, 
>>> toward more regular release cycles. 
>>> 
>>> 
>>> > On 8 Oct 2025, at 06:41, Štefan Miklošovič  wrote:
>>> > 
>>> > This is indeed an interesting idea but please let me share my point of 
>>> > view and somehow different opinion on that.
>>> > 
>>> > I share the questions with Jeff and Jeremiah a lot. I see it similarly 
>>> > and they got the point.
>>> > 
>>> > Before 5.0 was out, we had quite a situation where we officially had to 
>>> > take care of 3.0, 3.11, 4.0

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

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  wrote:
>>> I wanted to share some thoughts from a user perspective

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

On Thu, Oct 16, 2025 at 7:41 AM Josh McKenzie  wrote:

>
>1. We as a community collaborated on CEP-21 (TCM)
>
> ,
>discussed it
>,
>and voted to approve it
>
>   1. For people that have concerns about TCM informed by their
>   attempts to use or qualify trunk, providing concrete feedback to the
>   authors is the best way to get things addressed
>   2. I believe there is signal here for us to discuss a collective
>   "Definition of Done" to consider future features ready for exposure to
>   users (not necessarily to merge)
>
>
Thanks for calling this out.

I am all for listening to concerns about rough edges. It is imperative to
file those issues as JIRAs or bring them as discussions to the dev list.
The outcome could range from improvements / refinements of the feature to
improved governance standards for the project. Everybody, regardless of
their role on the project, should be playing a part in this process.

thanks,

Dinesh

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

2025-10-18 Thread Chris Lohfink

>
> But it should include all features from trunk that we consider to be
> production ready (that includes TCM in my book)


Please no TCM/accord. That is why everyone will be on 5.0/5.1 for years.
I'll be the person to say it outloud. I'm happy to be proven wrong but
let's be realistic.

Chris

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

> For instance, when upgrading to 5.1, a lack of a straightforward rollback 
> path can make the process risky.

@Jaydeep Chovatia, could you elaborate on this, since to my best knowledge 
there _is_ a straightforward rollback path for the features I am aware of. You 
can enable Accord transactions and later disable them, and you can also migrate 
back to Gossip from TCM. Both of these upgrade/downgrade paths are thoroughly 
tested. If there are other features that lack downgrade path, please mention 
them.

On Sun, Oct 12, 2025, at 9:12 PM, Jaydeep Chovatia wrote:
> Here is my opinion.
> 
> >– Unofficial branches will miss correctness and compatibility fixes unless 
> >their maintenance is made a burden for all committers. If not, they’ll be 
> >buggier and more prone to data loss than trunk.
> 
> Typically, the backporting effort is handled by the author or co-author of a 
> given CEP. As long as they are motivated to pursue the backport, I don’t 
> anticipate this being a concern. In most cases, their motivation naturally 
> comes from the fact that they are themselves relying on or benefiting from 
> the backported version.
> 
> >– The upgrade matrix becomes more complicated. As features are backported, 
> >any change affecting internode messaging, config properties, etc. becomes a 
> >potential compatibility breakage on upgrade, and these upgrade paths will be 
> >untested and unexercised.
> >– There’s an assumption in this thread that backports are easy to pick up. 
> >Backporting is often not straightforward and requires a high degree of 
> >understanding of the surrounding context, integration points, and what’s 
> >changed across branches.
> 
> As discussed earlier, we should conduct a formal vote on any proposed 
> backports and exercise caution with those that alter internal communication 
> mechanisms, Gossip protocols, or introduce backward incompatibilities. 
> Backports should meet a higher threshold—either by addressing fundamental 
> gaps in the database framework or by delivering substantial 
> reliability/efficiency improvements. For instance, CEP-37 and JDK 17/21 are 
> strong candidates for backporting: the former is essential to maintaining 
> data correctness in Cassandra, while the latter has become necessary as much 
> of the industry has already transitioned beyond JDK 11.
> 
> >– The proposal runs counter to the goal of “people running the database and 
> >finding + fixing issues.” I happily run trunk, but I don’t want to be the 
> >only one running trunk if others are committing changes to it. Committing 
> >changes to trunk then backporting them to releases considered “stable” 
> >doesn’t produce a more stable database.
> >– Backports branches don’t solve the “some people run forks” problem.
> >– Increasing the user community’s confidence in running new releases of the 
> >database. A lot of people are reluctant to upgrade, but it’s so much safer 
> >and easier than since the 2.x/3.x days. We want people to be confident 
> >running new releases of the database, not clinging to a branch.
> >– Deploying trunk and reporting back. Contributors of new features they’d 
> >like to backport should deploy and operate trunk. It’s the best way to 
> >establish confidence and makes Cassandra better for everybody.
> 
> I must acknowledge that the upgrade process has come a long way since the 2.x 
> and 3.x versions, but there’s still room for improvement. For instance, when 
> upgrading to 5.1, a lack of a straightforward rollback path can make the 
> process risky. This limitation often slows modernization efforts, as teams 
> are understandably hesitant to proceed without a reliable fallback. Many 
> businesses around the world run critical workloads on Cassandra, and an 
> outage caused by an upgrade would ultimately fall on the decision 
> makers—making them cautious about taking such risks. 
> This concern is precisely why many decision makers prefer to backport 
> features (such as CEP-37, JDK 17/21) and operate on private forks rather than 
> upgrade to 5.1. This proposal aims to make their lives easier by providing an 
> official and coordinated path for backporting, rather than leaving each 
> operator to maintain their own fork. For example, support for JDK 17 or 21 on 
> version 4.1 is already a widespread need among operators.
> We should certainly begin a new discussion on how to make our upgrade/new 
> versions process safer, so that, in the long run, the need for backporting 
> and similar discussions is eliminated.
> 
> >– Increasing release velocity. We do need to improve here and I’d be open to 
> >5.1.
> 
> I am not sure that’s the case. For most decision makers, the primary concern 
> isn’t velocity but safety. The key question they ask themselves is, ‘What is 
> my fallback plan?’ If that plan appears uncertain or risky, they are 
> understandably hesitant to proceed with an upgrade.
> 
> 
> Jaydeep
> 
> On Sun, Oct 12, 2025 at 9:04 AM  wrote:
>> I don’t think we have c

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

> I like your "cassandra-5.1, only add those 2 features" idea too Stefan
but feel like there's value in exploring the "why don't we backport to GA?"
question a bit further in isolation

I was thinking about this a lot recently and I just feel uneasy about
messing up with 5.0.x. I know I was proposing this myself but I do not have
a problem changing my mind. I don't know ... it just feels wrong to do
that. Java 21 into a _patch release_? A stable release should be just
something I literally copy jars over and I am done. I am not completely
sure the same level of trust might be put into backporting stuff etc.

I know that it is more work but all things considered I think 5.1 with a
strict limit on features is just the best way forward.

I am not sure we have the luxury of exploring that, we can't make mistakes
here, we have just one shot at this, basically.

Really on the edge with this one. Really interesting topic indeed.

On Mon, Oct 13, 2025 at 8:28 PM Josh McKenzie  wrote:

> What one team considers ready and low risk, another team begs not to be
> included. I suspect if there was really, truly a shared understanding of
> “this is back port ready, low risk, ready to run”, we could just put it
> into the existing branches (with a “yes this is a feature, but it’s a
> feature we all trust” discussion)?
>
> I don't think we've tested this enough to know. We've drawn a hard line in
> the sand of "no backports of improvements or new features" as one of our
> many efforts at stabilizing the database; I haven't seen anyone make a
> strong argument against back-porting JDK21 support or CEP-37 for instance.
> So we haven't had these debates in a structured fashion yet; you might be
> right, but there may be ways we can mitigate that and move that needle.
>
> My personal .02: I'd be comfortable with us allowing select backports to
> GA branches if we had some clear community consensus on the dev ML. I don't
> think it'd destabilize the DB if we were judicious about what we chose, and
> I believe on the whole users would prefer that balance vs. multi-year waits
> for new releases, new functionality, and all the qualification burden that
> comes from how "fat" our releases are.
>
> If the requirements were clear and agreed upon, something like:
>
>1. Someone must be running it in prod on >= N clusters for >= M time
>(TBD) and vouch for their experience with it
>2. Must be disabled by default / feature flagged
>3. Must be able to easily and gracefully disable the feature w/out
>breaking your cluster, taking downtime, or otherwise impacting prod
>4. Must be agreed upon by majority of PMC roll-called quorum on dev
>[DISCUSS] / [VOTE] thread for feature
>5. Must be clearly and thoroughly documented (user, operator, dev docs
>in code-base and on website)
>
> I'd personally be happy with that.
>
> (I like your "cassandra-5.1, only add those 2 features" idea too Stefan
> but feel like there's value in exploring the "why don't we backport to GA?"
> question a bit further in isolation)
>
> On Mon, Oct 13, 2025, at 2:13 PM, Štefan Miklošovič wrote:
>
> What about this: do a proper 5.1 branch with everything (pipelines,
> release ...) but put there only Java 21 support and CEP-37?
>
> Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0
> intact, 5.1 would be a branch we try this new model in, learn the lessons
> from it. When we support Java 21 and CEP-37 as only two changes and nothing
> else, it will already address Java 21 / unsupported Java 17 concerns and it
> would bring a lot of relief to people trying to transition to 6.0
> eventually and they would have some time to prepare for that. Then, in 6.0,
> TCM / Accord would be production ready waiting for them to migrate to,
> while they would already be on Java 21 + repairs.
>
> So for a while we would have
>
> 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>
> Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
>
> 5.0 -> 5.1 -> 6.0 -> trunk
>
> Then we can do 6.1 branch and we will have some experience of what worked
> / did not and we will be more ready to backport more or we will just
> abandon this altogether.
>
> My idea is to just do something quick yet already beneficial. If we
> backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth,
> nothing new will be there to cause any friction.
>
> As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 ->
> 5.1 would be very easy, in majority of cases just clean merges up.
>
> The only overhead is CI but we have pre-ci too which we can leverage so ...
>
> I would be more open to this if we agreed that the scope of the
> backporting on this initial pilot will be limited to a minimum of features
> and nothing else. Then we can just reflect on what we did.
>
> On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
>
>
>
> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  wrote:
> >
> > To respond to some of the other points and throw my per

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

2025-10-18 Thread Patrick Lee

100% in favor and how ever i can be involved here i'm game!  I've been
involved with deciding to have our own internal fork for this purpose but
there is some hesitation for the same reason that Jaydeep says.  I did
early on backport CEP-37 for Cassandra 5 and was running tests before it
was merged into trunk but we didn't go beyond that. We have a lot of 4.0
and 5.0 in our fleet as we basically overlooked 4.1. So having things like
CEP-37 in a 5..0 code base i'm all in!

On Mon, Oct 6, 2025 at 1:42 PM Jaydeep Chovatia 
wrote:

> Totally in support of this idea. As we know, CEP-37 has already been
> merged into the trunk. However, many individuals who are not on the trunk
> have been using the CEP-37 work on 4.1. Therefore, I have been maintaining
> a private fork (
> https://github.com/jaydeepkumar1984/cassandra/tree/auto_repair_v2_on_4_1),
> which is quite painful to manage. I have more 4.1 users inquiring about
> using this, as they are now aware that the CEP-37 4.1 work is already in
> use by Cassandra operators and is pretty stable, and they are already on
> 4.1. So more and more folks are going to rely on my private fork, which is
> not a great idea either.
>
> I am in favor of officially supporting these features backport. Of course,
> we collectively vote on which features to backport and which ones not to.
>
> Jaydeep
>
> On Mon, Oct 6, 2025 at 11:35 AM Isaac Reath  wrote:
>
>> I’m in favor of this idea for all of the reasons Josh mentioned and I’m
>> happy to help out with the curation and maintenance. Consolidating these
>> efforts seems like a clear win to anyone who is already managing their own
>> fork of backports.
>>
>> A couple of questions that come to mind:
>>
>> 1) What is the inclusion criteria for a patch to get backported?
>>
>> 2) What does the lifecycle of this branch look like? If we use the
>> example of a cassandra-5.1 branch, what happens to this branch after 6.0 is
>> GA? I think there should be some grace period after the next version is cut
>> where this branch is still active, but we probably don't need as long of a
>> support model as the "main" (i.e. 4.0, 4.1, 5.0, 6.0) releases.
>>
>>
>> On Mon, Oct 6, 2025 at 1:39 PM Rahul Singh (ANANT) 
>> wrote:
>>
>>> Makes sense. Does this become "LTS" ? or is this something else.
>>>
>>>
>>> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:
>>>
 On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:
 Many large‑scale Cassandra users have had to maintain private feature
 back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on
 older branches. That duplication adds risk and pulls time away from
 upstream contributions which came up as a pain point in discussion at CoC
 this year.
 The proposal we came up with: an official, community‑maintained
 backport branch (e.g. cassandra‑5.1) built on the current GA release that
 we pilot for a year and then decide if we want to make it official. The
 branch would selectively accept non‑disruptive improvements that meet
 criteria we define together. There’s a lot of OSS prior art here (Lucene,
 httpd, Hadoop, Kafka, Linux kernel, etc).
 Benefits include reduced duplicated effort, a safer middle ground
 between trunk and frozen GA releases, faster delivery of vetted features,
 and community energy going to this branch instead of duplicated on private
 forks.
 If you’re interested in helping curate or maintain this branch - or
 have thoughts on the idea - please reply and voice your thoughts.
 ~Josh

>>>
>>>
>>>

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

I agree with all of that, Alex.

Plus, I am not completely sure how that would look like in practice,
e.g. porting TCM to 5.0, (maybe somebody already has a fork like that
so they can elaborate more), but my guess is that thing like that
would be quite tricky to backport. All I am saying is that it might be
more work than anticipated, then we would be porting for next half a
year with all "ah we need to tweak this here as well to have backport
right" and it might actually produce way more work than if somebody
just upgraded and be done with it.

On Mon, Oct 13, 2025 at 11:04 AM Alex Petrov  wrote:
>
> > For instance, when upgrading to 5.1, a lack of a straightforward rollback 
> > path can make the process risky.
>
> @Jaydeep Chovatia, could you elaborate on this, since to my best knowledge 
> there _is_ a straightforward rollback path for the features I am aware of. 
> You can enable Accord transactions and later disable them, and you can also 
> migrate back to Gossip from TCM. Both of these upgrade/downgrade paths are 
> thoroughly tested. If there are other features that lack downgrade path, 
> please mention them.
>
> On Sun, Oct 12, 2025, at 9:12 PM, Jaydeep Chovatia wrote:
>
> Here is my opinion.
>
> >– Unofficial branches will miss correctness and compatibility fixes unless 
> >their maintenance is made a burden for all committers. If not, they’ll be 
> >buggier and more prone to data loss than trunk.
>
> Typically, the backporting effort is handled by the author or co-author of a 
> given CEP. As long as they are motivated to pursue the backport, I don’t 
> anticipate this being a concern. In most cases, their motivation naturally 
> comes from the fact that they are themselves relying on or benefiting from 
> the backported version.
>
> >– The upgrade matrix becomes more complicated. As features are backported, 
> >any change affecting internode messaging, config properties, etc. becomes a 
> >potential compatibility breakage on upgrade, and these upgrade paths will be 
> >untested and unexercised.
> >– There’s an assumption in this thread that backports are easy to pick up. 
> >Backporting is often not straightforward and requires a high degree of 
> >understanding of the surrounding context, integration points, and what’s 
> >changed across branches.
>
> As discussed earlier, we should conduct a formal vote on any proposed 
> backports and exercise caution with those that alter internal communication 
> mechanisms, Gossip protocols, or introduce backward incompatibilities. 
> Backports should meet a higher threshold—either by addressing fundamental 
> gaps in the database framework or by delivering substantial 
> reliability/efficiency improvements. For instance, CEP-37 and JDK 17/21 are 
> strong candidates for backporting: the former is essential to maintaining 
> data correctness in Cassandra, while the latter has become necessary as much 
> of the industry has already transitioned beyond JDK 11.
>
> >– The proposal runs counter to the goal of “people running the database and 
> >finding + fixing issues.” I happily run trunk, but I don’t want to be the 
> >only one running trunk if others are committing changes to it. Committing 
> >changes to trunk then backporting them to releases considered “stable” 
> >doesn’t produce a more stable database.
> >– Backports branches don’t solve the “some people run forks” problem.
> >– Increasing the user community’s confidence in running new releases of the 
> >database. A lot of people are reluctant to upgrade, but it’s so much safer 
> >and easier than since the 2.x/3.x days. We want people to be confident 
> >running new releases of the database, not clinging to a branch.
> >– Deploying trunk and reporting back. Contributors of new features they’d 
> >like to backport should deploy and operate trunk. It’s the best way to 
> >establish confidence and makes Cassandra better for everybody.
>
> I must acknowledge that the upgrade process has come a long way since the 2.x 
> and 3.x versions, but there’s still room for improvement. For instance, when 
> upgrading to 5.1, a lack of a straightforward rollback path can make the 
> process risky. This limitation often slows modernization efforts, as teams 
> are understandably hesitant to proceed without a reliable fallback. Many 
> businesses around the world run critical workloads on Cassandra, and an 
> outage caused by an upgrade would ultimately fall on the decision 
> makers—making them cautious about taking such risks.
> This concern is precisely why many decision makers prefer to backport 
> features (such as CEP-37, JDK 17/21) and operate on private forks rather than 
> upgrade to 5.1. This proposal aims to make their lives easier by providing an 
> official and coordinated path for backporting, rather than leaving each 
> operator to maintain their own fork. For example, support for JDK 17 or 21 on 
> version 4.1 is already a widespread need among operators.
> We should certainly begin a new discussi

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

Let me explain my understanding by using an example: backports, such
as *Backport#1:
CEP-37* and *Backport#2: JDK 21* to 4.1.

   1. To simplify the example (just for the sake of this discussion only),
   let me name our existing 4.1 branch to *4.1-bugfixes*, which would
   continue to receive only bugfixes that we have already been doing
   2. Create a new branch, say, *4.1-bugfixes-backport* (parent: 4.1-
   *bugfixes*)

>1.) Should we have a mechanism to backport CEP-37, Java 21, and things
like them that do not introduce messaging or on-disk version changes?
(Yes/No)
Yes, and it should go through a rigorous community vote. Backporting a
feature should have an extremely high bar.

>2.) Where should those backports happen? (An existing major version
branch/a new branch/it depends on the feature)
Backport#1 and Backport#2 would go to *4.1-bugfixes-backport**. *

Later, if a person P1 fixes some bug B1 on 5.0/trunk, and if that bug needs
to be ported to *4.1-bugfixes*, then that person P1 also needs to port the
bug to *4.1-bugfixes-backport*
So at this point, this is how both the branches would look:

4.1-*bugfixes*
- Contains B1

4.1-*bugfixes-backport*
- Contains B1 + Backport#1 + Backport#2

Jaydeep

On Mon, Oct 13, 2025 at 2:32 PM Caleb Rackliffe 
wrote:

> Forgot...
>
> 4.) If a new branch is introduced, what should be the fate of
> cassandra-4.0? (make unsupported when the new branch releases/keep until
> 6.0 releases)
>
> On Mon, Oct 13, 2025 at 4:23 PM Mick  wrote:
>
>>
>>
>> > On 13 Oct 2025, at 20:13, Štefan Miklošovič 
>> wrote:
>> >
>> > What about this: do a proper 5.1 branch with everything (pipelines,
>> release ...) but put there only Java 21 support and CEP-37?
>> >
>> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0
>> intact, 5.1 would be a branch we try this new model in, learn the lessons
>> from it. When we support Java 21 and CEP-37 as only two changes and nothing
>> else, it will already address Java 21 / unsupported Java 17 concerns and it
>> would bring a lot of relief to people trying to transition to 6.0
>> eventually and they would have some time to prepare for that. Then, in 6.0,
>> TCM / Accord would be production ready waiting for them to migrate to,
>> while they would already be on Java 21 + repairs.
>>
>>
>> Yes Stefan, this has my vote.  This is an approach that is known and
>> tangible to us, and bounded.
>>
>> I do believe it will help both user and downstreamers move closer to
>> trunk.  This is a good thing, and the burden it introduces: forward merging
>> and upgrade paths; we can manage (and importantly it's those more active on
>> older branches that are now agreeing to this).
>>
>> We're also acknowledging that this is attracting new contributors, which
>> may be a net-win for us.
>>
>>

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

What remains unclear to me even after reading entire thread is upgrade and 
downgrade paths. It is extremely complicated to keep our current upgrade and 
downgrade paths working, and we have only gotten to a point where we have them 
well tested [1].

Between system schema changes (which most major features include), file format 
changes, messaging and client protocol changes, plus things like storage 
compatibility mode, people may get stranded on the branch with potentially 
complex migration paths.

How are you going to ensure people can actually migrate between branches, and 
switch back to mainline if/when needed? Will this also impose extra effort on 
active maintainers / developers, where they will be required to develop a 
migration patch for some specific, potentially never deployed, combination of 
features?

[1] https://issues.apache.org/jira/browse/CASSANDRA-14937

On Mon, Oct 6, 2025, at 6:03 PM, Josh McKenzie wrote:
> Many large‑scale Cassandra users have had to maintain private feature 
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on 
> older branches. That duplication adds risk and pulls time away from upstream 
> contributions which came up as a pain point in discussion at CoC this year.
> 
> The proposal we came up with: an official, community‑maintained backport 
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot for 
> a year and then decide if we want to make it official. The branch would 
> selectively accept non‑disruptive improvements that meet criteria we define 
> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop, Kafka, 
> Linux kernel, etc).
> 
> Benefits include reduced duplicated effort, a safer middle ground between 
> trunk and frozen GA releases, faster delivery of vetted features, and 
> community energy going to this branch instead of duplicated on private forks.
> 
> If you’re interested in helping curate or maintain this branch - or have 
> thoughts on the idea - please reply and voice your thoughts.
> 
> ~Josh

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

I’m not sure where the word unofficial came from.

The question is only if we merge every commit to it or no.

If every commit is merged to it, it’s not a “backport branch”, it’s just a 
regular release version, just created retrospectively, and should be presented 
as such. 

If it’s a regular release (5.1), and every commit that is merged into 5.0 will 
go to 5.1, it’s a different discussion: it will have to be added to future 
branches as a separate version, and maintained for upgrade paths from 4.0 
upwards. 

On Mon, Oct 13, 2025, at 9:55 PM, Dinesh Joshi wrote:
> The title of this thread is “[DISCUSS] Pilot program of an officially 
> supported backport branch”
> 
> I want to draw attention to the word _official_. There is nothing unofficial 
> about what is being discussed here. I am not sure why is that word being 
> thrown around in the thread.
> 
> To the PMCs and Committers on this project in this thread - we are talking 
> about our project’s governance and the OFFICIAL policy around backports. I 
> hope this clarifies what the goal of this thread and discussion is.
> 
> There was a prior mentions about this being a branch where backported code 
> would live and will be untested. Let me clarify that we’re not talking about 
> just a branch. The project will create artifacts and release them. Having 
> code living in a repository without being released runs counter to ASF’s 
> principles.
> 
> Thanks,
> 
> Dinesh
> 
> On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe  
> wrote:
>> This sort of has to be about something we’ll do officially as a project, or 
>> the original post is little more than asking what we think about a public 
>> fork, which (as bad as it would look for the project) nobody really needs 
>> approval to do anyway, right?
>> 
>>> On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
>>> 
>>> Thank you for the pointer but I did read it.
>>> 
>>> My point is that this thread seems to have gone from “let’s create a branch 
>>> to electively pull changes into” to “we are retrospectively adding a 5.1 
>>> branch somewhere between 5.0 and current trunk”, which I think is a 
>>> completely different discussion.
>>> 
>>> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
 I am afraid something like an "enthusiast-driven branch" is not a
 thing. Please read the last email of Jeff, first section.
 
 On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
 >
 > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
 >
 > Could you elaborate: I was under impression the new branch is going to 
 > be maintained by a group of enthusiasts. Are we now considering making 
 > this new branch in the upgrade path? This sounds rather different from 
 > the original idea of having an officially supported back port branch.
 >
 > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
 >
 > What about this: do a proper 5.1 branch with everything (pipelines, 
 > release ...) but put there only Java 21 support and CEP-37?
 >
 > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
 > intact, 5.1 would be a branch we try this new model in, learn the 
 > lessons from it. When we support Java 21 and CEP-37 as only two changes 
 > and nothing else, it will already address Java 21 / unsupported Java 17 
 > concerns and it would bring a lot of relief to people trying to 
 > transition to 6.0 eventually and they would have some time to prepare 
 > for that. Then, in 6.0, TCM / Accord would be production ready waiting 
 > for them to migrate to, while they would already be on Java 21 + repairs.
 >
 > So for a while we would have
 >
 > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
 >
 > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
 >
 > 5.0 -> 5.1 -> 6.0 -> trunk
 >
 > Then we can do 6.1 branch and we will have some experience of what 
 > worked / did not and we will be more ready to backport more or we will 
 > just abandon this altogether.
 >
 > My idea is to just do something quick yet already beneficial. If we 
 > backport only Java 21 and CEP-37 then upgrade paths will be pretty 
 > smooth, nothing new will be there to cause any friction.
 >
 > As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 
 > -> 5.1 would be very easy, in majority of cases just clean merges up.
 >
 > The only overhead is CI but we have pre-ci too which we can leverage so 
 > ...
 >
 > I would be more open to this if we agreed that the scope of the 
 > backporting on this initial pilot will be limited to a minimum of 
 > features and nothing else. Then we can just reflect on what we did.
 >
 > On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
 >
 >
 >
 > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  
 > > wrote:
 > >
 > > To respond to some of the other points an

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

2025-10-18 Thread Francisco Guerrero

Should we make it a strict requirement that all backported features
have to have the ability to be feature-flagged, and they should be
feature-flagged off by default? This will help with the stability of the
*backport* branch.

Best,
- Francisco

On 2025/10/09 15:59:52 Josh McKenzie wrote:
> > if we introduce bad bugs a long way into a stable branch, e.g. 5.0.18;  
> > that's a really bad look for us and I fear will burn operators bad enough 
> > that we will lose users over it.
> I agree with this statement. The nuance is that it wouldn't be on a *stable* 
> branch, it'd be on a *backport* branch. Now - if we don't think users will 
> understand the distinction between Stable and Backport, that's a reasonable 
> conversation to have for sure. Or if we think going from 5.0.X as stable to 
> 5.0.X as backport would be disruptive and break contract.
> 
> That said, the same requirement of users to understand the distinction would 
> hold whether our backport branch was 5.0.X or 5.1.X.
> 
> On Thu, Oct 9, 2025, at 11:48 AM, Mick wrote:
> > 
> > 
> > > If we have multiple private forks running large scale fleets w/backported 
> > > features, having that same code on the latest GA branch doesn't unduly 
> > > jeopardize the stability of that branch.
> > 
> > 
> > I don't agree with this extrapolation, and believe we have already been 
> > burnt by it.
> > 
> > Having someone run something in their production does not mean it meets our 
> > GA standard.
> > Even fleets of clusters within one company has a homogeneous deployment, 
> > and often a narrow bound of permitted data models.
> > 
> > It certainly heaps, and can be critically unique feedback in helping us get 
> > to GA, but it is certainly not alone universal, and that does matter for 
> > our stable branches and the trillions of possible combinations of 
> > configurations and data models operators can find themselves with.
> > 
> > I want to repeat my earlier statement:  if we introduce bad bugs a long way 
> > into a stable branch, e.g. 5.0.18;  that's a really bad look for us and I 
> > fear will burn operators bad enough that we will lose users over it.
> > 
> > It might be more constructive at this point to go through the examples of 
> > what folk are now running in production in down-streams and are they 
> > initial candidates for back-porting.
>

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

This is indeed an interesting idea but please let me share my point of view
and somehow different opinion on that.

I share the questions with Jeff and Jeremiah a lot. I see it similarly and
they got the point.

Before 5.0 was out, we had quite a situation where we officially had to
take care of 3.0, 3.11, 4.0 and 4.1 at the same time. If a bug was found,
we had to patch 5 branches at once (trunk as well). That meant 5 CI jobs.
The patching was an endeavour spanning multiple days, realistically. Once
5.0 got out, we officially discontinued 3.0 and 3.11. But what I have been
experiencing was that this information about not supporting 3.0 / 3.11 was
spreading very slowly among people / customers and I / we had to repeatedly
explain to everybody that yes, 3.0 and 3.11 and done. What are they? Done?
Yes, done. 3.0 and 3.11 are finished. Finished you say? That means no
patches? Yes, no patches. Aha right ... For real? ... you got it. People
had to internalize that it is just not going to happen.

When we "open the flood gates" then the existence of a backporting branch
will be the justification of anything they want to see there because they
do not want to upgrade. Instead of us working towards a more smooth upgrade
we are burying ourselves with older stuff. That slows adoption of new
majors a lot. People will not be forced to, there will be way less
incentive to do that when all the important goodies are backported anyway.

I see that "the backports would be non-disruptive but potentially higher
risk". I do not completely understand what this means in practice. Let's
say CEP-37. Is that disruptive or not? What's the definition of that? To
me, correct me if I am wrong, is that something is disruptive if I just can
not turn it off even if I do not want to use it. Does one _have to_ use
CEP-37 when it is backported? No. They can just turn it off. So what is
exactly the risk of introducing it to e.g. 5.0.x ?

Also, how are upgrades done? People are going to upgrade from 5.0.x to 5.1
and then it will be possible to upgrade to 6.0 from 5.1? This would need us
to make the pipelines, incorporate this new path into upgrade tests and so
on ... a lot of work.

I think that the current policy - "only bug fixes to older branches" might
be relaxed a bit instead and leverage already existing upgrade paths and
infrastructure to test it all instead of creating brand new branches we
need to take care of.

Regards

On Mon, Oct 6, 2025 at 6:04 PM Josh McKenzie  wrote:

> Many large‑scale Cassandra users have had to maintain private feature
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on
> older branches. That duplication adds risk and pulls time away from
> upstream contributions which came up as a pain point in discussion at CoC
> this year.
>
> The proposal we came up with: an official, community‑maintained backport
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot
> for a year and then decide if we want to make it official. The branch would
> selectively accept non‑disruptive improvements that meet criteria we define
> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop,
> Kafka, Linux kernel, etc).
>
> Benefits include reduced duplicated effort, a safer middle ground between
> trunk and frozen GA releases, faster delivery of vetted features, and
> community energy going to this branch instead of duplicated on private
> forks.
>
> If you’re interested in helping curate or maintain this branch - or have
> thoughts on the idea - please reply and voice your thoughts.
>
> ~Josh
>

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

> Any protocol changes in the backport branch would need to be validated from 
> 5.0 and to 6.0, but otherwise not increase the surface area of breakage.

This sounds like backport branches are going to create substantial burden for 
active maintainers. 

For most of the discussion it sounded more like a backport branch will be 
created and maintained by a select group of volunteers who want to help the 
community by making a small number of patches also available in other branches. 
This means it will not be on an active merge path (i.e., when merging something 
into 5.0, you skip the backport branches and go straight to 6.0), and all 
changes will be pulled there electively. Also, active maintainers will not have 
to reason through which backport branches there exist and which compatibility 
implications they impose. 

Has this changed over the course of the discussion?

On Mon, Oct 13, 2025, at 4:02 PM, Josh McKenzie wrote:
> To respond to some of the other points and throw my perspective into the mix:
> 
>> Release engineering for a branch is nearly a full-time job.
> While release management is a burden (and one we've had a hard time 
> resourcing for years), I don't see it as being nearly a full-time job per 
> branch. We also have contributors willing to step forward and take on this 
> extra work and plenty of opportunity for automation on both release 
> preparation and validation that would lower that burden further.
> 
>> Unofficial branches will miss correctness and compatibility fixes unless 
>> their maintenance is made a burden for all committers.
> Both proposals (backport to 5.0, support a 5.1 that accepts backport) would 
> be considered official during the pilot. Bugfixes that are 5.0 or older would 
> have 1 more branch they needed to apply to and merge through.
> 
>> – The upgrade matrix becomes more complicated. As features are backported... 
>> these upgrade paths will be untested and unexercised.
> I agree the matrix would become more complicated but disagree that they would 
> be untested and unexercised. I also think the marginal increase in complexity 
> is worth taking on for the expected benefits.
> 
> For example, with the "cassandra-5.1-backport" branch, we could support:
>  • 4.1-5.0
>  • 5.0-6.0
>  • (new) 5.0-5.1-6.0
> 
> This would add 2 new paths to test and add one backport-branch-specific 
> constraint (must go through 5.0 to get to 5.1). Any protocol changes in the 
> backport branch would need to be validated *from *5.0 and *to *6.0, but 
> otherwise not increase the surface area of breakage.
> 
> Those types of changes would already need to be verified in the current 
> status quo in the 5.0-6.0 path; introducing a branch in the middle that 
> received a backport would involve validating that same functional change from 
> 5.0-5.1 as from 5.0-6.0 prior, just in whatever differing context might be on 
> that branch.
> 
>> – There’s an assumption in this thread that backports are easy to pick up.
> I see this discussion as an exploration on how skilled contributors and 
> committers can deduplicate their work on private forks, bring those forks 
> closer to upstream, and make certain new features available to end users 
> earlier. I haven't read anything as implying backporting is easy.
> 
>> – Backports branches don’t solve the “some people run forks” problem.
> I see this a bit differently; it doesn't "solve" the problem (I don't 
> personally see this as a problem to be solved fwiw), but it does bring those 
> forks much closer to upstream and move engineering effort that would 
> otherwise be on private forks into the public space benefiting everyone.
> 
>> – Backports branches don’t solve the user community adoption problem either, 
>> unless we’re also publishing per-OS packages, Maven artifacts, etc.
> I agree with you that we have a "time to new release" adoption problem 
> broadly but I don't see this thread as attempting to address that; do we 
> think providing a middle-ground release between frozen GA and feature-dense 
> higher risk trunk would worsen adoption?
> 
> ---
> 
> I think a follow-up discussion about how we can enable and encourage users to 
> test trunk or run releases cut from it (alphas cut monthly or quarterly) 
> would be a great use of our time and energy.
> 
> I also think it would be valuable to have a follow up discussion about how we 
> can change our engineering practices to make GA releases less disruptive for 
> users to transition onto, allow users to incrementally validate new optional 
> features, and roll back to older releases with confidence in the event of 
> defects (see prior email).
> 
> 
> On Sun, Oct 12, 2025, at 12:03 PM, [email protected] wrote:
>> I don’t think we have consensus on this thread, but it feels like some are 
>> pushing forward as if we do (“If everybody is generally onboard with the 
>> proposal, we can start getting into the details of the logistics…,” followed 
>> by discussion of logistics).
>> 
>

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

> What about the following idea: allow community-approved feature backports
to *latest GA* (with a brief window allowing backports to 2 GA branches)
and tier releases as follows

Yeah, I would rather have this than separate, "second-class citizen"
branches. It relies on us exercising good judgement about what gets in, but
it doesn't discourage upgrades or (de-facto) introduce a new branch in the
normal development workflow.

On Wed, Oct 8, 2025 at 1:07 PM Jaydeep Chovatia 
wrote:

> >What about the following idea: allow community-approved feature backports
> to *latest GA* (with a brief window allowing backports to 2 GA branches)
> and tier releases as follows:
>
> Makes sense to me. We can define a policy, such as initiating a thread,
> similar to "VOTE," and requiring three binding votes and no vetoes, etc.
> Initially, we can be more conservative by increasing the binding vote count
> from 3 to 5 or even higher; that way, everyone will have a chance to
> provide an opinion, yet it remains structured enough so that only
> community-intended features get backported.
>
> Jaydeep
>
> On Wed, Oct 8, 2025 at 7:59 AM Štefan Miklošovič 
> wrote:
>
>>
>>
>> On Wed, Oct 8, 2025 at 2:53 PM Josh McKenzie 
>> wrote:
>>
>>> Thanks for the discussion - it looks like we agree on the problem and
>>> the trade‑offs involved.
>>>
>>> Maintaining an extra branch would add toil: we’d have to merge bug
>>> fixes, run CI (including upgrade tests), and extend the already lengthy
>>> upstream path. A simpler alternative is to relax our backport restrictions
>>> on GA branches.
>>>
>>
>> Yes, this would mean CEP-37 would go to 5.0.x, for example. I do not have
>> a problem with that in general, I am just not sure if we can "abuse" a
>> patch release for this kind of addition. It would really have to be
>> "non-disruptive as much as possible". This would be in line with what Jeff
>> / Jeremiah / myself were suggesting as well. We would not need to introduce
>> a new branch, upgrade paths would be tested as they are now, bug fixes
>> would be added too ...
>>
>> Looking forward to the opinions of other people.
>>
>>
>>>
>>> What about the following idea: allow community-approved feature
>>> backports to *latest GA* (with a brief window allowing backports to 2
>>> GA branches) and tier releases as follows:
>>>
>>> *When a new release is cut:*
>>>
>>>- New release / Latest GA (6.0): stabilizing (backports accepted)
>>>- Middle GA (5.0): backports accepted
>>>- Oldest GA (4.1): stable
>>>
>>> *When the new release stabilizes:*
>>>
>>>- Latest GA (6.0): backports accepted
>>>- Middle GA (5.0): stable
>>>- Oldest GA (4.1): stable
>>>
>>> This approach gives users a clear choice - stable, backport‑enabled, or
>>> a temporary stabilizing branch - without adding CI overhead.
>>>
>>> On Wed, Oct 8, 2025, at 5:42 AM, Štefan Miklošovič wrote:
>>>
>>> Hi Dinesh,
>>>
>>> thanks for reassuring that this branch would be really just for crucial
>>> functionality where benefits justify the backport. I would be more willing
>>> to entertain that idea but I still think that once people see 5.1 is up
>>> they will want to support their case and there will be a lot of pressure to
>>> backport this and that. Not all CEPs / features will make it. We need to be
>>> very selective. There will be a lot of "massaging" around what can go in
>>> and what not and the expectations would need to be set from the very
>>> beginning and followed.
>>>
>>> However, I am not still quite sure how that would work in general,
>>> reading Josh email here:
>>>
>>> "The branch would selectively accept non‑disruptive improvements that
>>> meet criteria we define together."
>>>
>>> Once people are on 5.1, they will want to have all the bug fixes in
>>> there as well. So instead of merging from 4.0 to 4.1, 5.0 and trunk, we
>>> will be doing 4.0. 4.1, 5.0, 5.1 and trunk?
>>>
>>> If the answer is yes, then we will have just another branch we need to
>>> fully maintain.
>>>
>>> If the answer is no, as in we will skip 5.1 on merges from 4.0 to trunk,
>>> then I think this will be met with disappointment and questions as to why
>>> we are not patching 5.1 as well.
>>>
>>> Basically we go all in and maintain 5.1 with all the patches from lower
>>> branches or we just maintain and backport important features but then ...
>>> who is going to use it like that - without receiving bug fixes.
>>>
>>>
>>>
>>> On Wed, Oct 8, 2025 at 9:46 AM Dinesh Joshi  wrote:
>>>
>>> Stefan, Sam – your concerns are absolutely valid and have come up in
>>> various discussions.
>>>
>>> Here's the reality though – many large operators of Cassandra are
>>> maintaining backports of various features. The proposal here is to try and
>>> allow these contributors to maintain them in the community instead of
>>> internally. This is a limited time pilot to see if this model could work.
>>>
>>> When we "open the flood gates" then the existence of a backporting
>>> branch will be the justifica

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

Forgot...

4.) If a new branch is introduced, what should be the fate of
cassandra-4.0? (make unsupported when the new branch releases/keep until
6.0 releases)

On Mon, Oct 13, 2025 at 4:23 PM Mick  wrote:

>
>
> > On 13 Oct 2025, at 20:13, Štefan Miklošovič 
> wrote:
> >
> > What about this: do a proper 5.1 branch with everything (pipelines,
> release ...) but put there only Java 21 support and CEP-37?
> >
> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0
> intact, 5.1 would be a branch we try this new model in, learn the lessons
> from it. When we support Java 21 and CEP-37 as only two changes and nothing
> else, it will already address Java 21 / unsupported Java 17 concerns and it
> would bring a lot of relief to people trying to transition to 6.0
> eventually and they would have some time to prepare for that. Then, in 6.0,
> TCM / Accord would be production ready waiting for them to migrate to,
> while they would already be on Java 21 + repairs.
>
>
> Yes Stefan, this has my vote.  This is an approach that is known and
> tangible to us, and bounded.
>
> I do believe it will help both user and downstreamers move closer to
> trunk.  This is a good thing, and the burden it introduces: forward merging
> and upgrade paths; we can manage (and importantly it's those more active on
> older branches that are now agreeing to this).
>
> We're also acknowledging that this is attracting new contributors, which
> may be a net-win for us.
>
>

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

2025-10-18 Thread Mick

> On 13 Oct 2025, at 20:13, Štefan Miklošovič  wrote:
> 
> What about this: do a proper 5.1 branch with everything (pipelines, release 
> ...) but put there only Java 21 support and CEP-37?
> 
> Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
> intact, 5.1 would be a branch we try this new model in, learn the lessons 
> from it. When we support Java 21 and CEP-37 as only two changes and nothing 
> else, it will already address Java 21 / unsupported Java 17 concerns and it 
> would bring a lot of relief to people trying to transition to 6.0 eventually 
> and they would have some time to prepare for that. Then, in 6.0, TCM / Accord 
> would be production ready waiting for them to migrate to, while they would 
> already be on Java 21 + repairs.

Yes Stefan, this has my vote.  This is an approach that is known and tangible 
to us, and bounded.

I do believe it will help both user and downstreamers move closer to trunk.  
This is a good thing, and the burden it introduces: forward merging and upgrade 
paths; we can manage (and importantly it's those more active on older branches 
that are now agreeing to this).

We're also acknowledging that this is attracting new contributors, which may be 
a net-win for us.

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

2025-10-18 Thread Dmitry Konstantinov

Regarding the JDK 21 support backport mentioned in the thread, is it really
the case even after we voted to backport support for new JDK versions
here?: https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 ?


On Tue, 14 Oct 2025 at 02:51, Jaydeep Chovatia 
wrote:

> >@Jaydeep Chovatia, could you elaborate on this, since to my best
> knowledge there _is_ a straightforward rollback path for the features I
> am aware of. You can enable Accord transactions and later disable them, and
> you can also migrate back to Gossip from TCM. Both of these
> upgrade/downgrade paths are thoroughly tested. If there are other features
> that lack downgrade path, please mention them.
>
> *Accord: *I had an opportunity to review Accord briefly, and based on my
> understanding, this feature appears to be backward compatible during
> upgrades. I also have a reasonable level of confidence in its rollback
> capabilities, as this aspect was discussed to some extent in the “CEP-15
> Update” mailing list thread.
>
> *TCM:* While I haven’t yet done an in-depth exploration of all its
> internals, after reviewing the CEP-21 proposal and our informal discussions
> during Community Over Code, my current impression is that rolling back from
> 5.1 to 5.0 after enabling TCM might be either highly complex or not
> feasible. Of course, I could be mistaken here. I really appreciate your
> clarification that rollback is fully supported and possible. Given that, it
> might be very valuable to document a detailed rollback plan (if none
> exists), corresponding rollback test cases (if none exists), and an
> [UPDATE] thread to help dispel the common perception that TCM lacks
> backward compatibility.
>
> Jaydeep
>
>
> On Mon, Oct 13, 2025 at 2:04 AM Alex Petrov  wrote:
>
>> > For instance, when upgrading to 5.1, a lack of a straightforward
>> rollback path can make the process risky.
>>
>> @Jaydeep Chovatia, could you elaborate on this, since to my best
>> knowledge there _is_ a straightforward rollback path for the features I
>> am aware of. You can enable Accord transactions and later disable them, and
>> you can also migrate back to Gossip from TCM. Both of these
>> upgrade/downgrade paths are thoroughly tested. If there are other features
>> that lack downgrade path, please mention them.
>>
>> On Sun, Oct 12, 2025, at 9:12 PM, Jaydeep Chovatia wrote:
>>
>> Here is my opinion.
>>
>> >– Unofficial branches will miss correctness and compatibility fixes
>> unless their maintenance is made a burden for all committers. If not,
>> they’ll be buggier and more prone to data loss than trunk.
>>
>> Typically, the backporting effort is handled by the author or co-author
>> of a given CEP. As long as they are motivated to pursue the backport, I
>> don’t anticipate this being a concern. In most cases, their motivation
>> naturally comes from the fact that they are themselves relying on or
>> benefiting from the backported version.
>>
>> >– The upgrade matrix becomes more complicated. As features are
>> backported, any change affecting internode messaging, config properties,
>> etc. becomes a potential compatibility breakage on upgrade, and these
>> upgrade paths will be untested and unexercised.
>> >– There’s an assumption in this thread that backports are easy to pick
>> up. Backporting is often not straightforward and requires a high degree of
>> understanding of the surrounding context, integration points, and what’s
>> changed across branches.
>>
>> As discussed earlier, we should conduct a formal vote on any proposed
>> backports and exercise caution with those that alter internal communication
>> mechanisms, Gossip protocols, or introduce backward incompatibilities.
>> Backports should meet a higher threshold—either by addressing fundamental
>> gaps in the database framework or by delivering substantial
>> reliability/efficiency improvements. For instance, CEP-37 and JDK 17/21 are
>> strong candidates for backporting: the former is essential to maintaining
>> data correctness in Cassandra, while the latter has become necessary as
>> much of the industry has already transitioned beyond JDK 11.
>>
>> >– The proposal runs counter to the goal of “people running the database
>> and finding + fixing issues.” I happily run trunk, but I don’t want to be
>> the only one running trunk if others are committing changes to it.
>> Committing changes to trunk then backporting them to releases considered
>> “stable” doesn’t produce a more stable database.
>> >– Backports branches don’t solve the “some people run forks” problem.
>> >– Increasing the user community’s confidence in running new releases of
>> the database. A lot of people are reluctant to upgrade, but it’s so much
>> safer and easier than since the 2.x/3.x days. We want people to be
>> confident running new releases of the database, not clinging to a branch.
>> >– Deploying trunk and reporting back. Contributors of new features
>> they’d like to backport should deploy and operate trunk. It’s t

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

2025-10-18 Thread Miklosovic, Stefan via dev

I want to stress that I would like 5.1 be with strictly limited on backported 
features, as I have written in my last email. It should really be just Java 21 
and CEP-37 and that’s it (plus bugfixes).

I do want to avoid the situation when various people (I already see some) are 
trying to ask if this and that will be backported. I really want to prevent 
features be backported extensively. We need to put some reasonable limit on 
this otherwise we will be experiencing constant nagging of the community why 
this or that is not backported and potentially severely preventing 6.0 from 
broader adoption. Plus the nagging might be so strong that after a while 5.1 
will be beyond recognition and it will be something nobody actually wanted to 
happen.

I want this to be part of the vote, what goes in, if we ever go vote on this 
proposal (we should). Nothing like “we will see”. No, let’s plan 5.1 ahead and 
just stick to that for the sake of the simplicity and at least some kind of 
predictability.

Regards

From: Josh McKenzie 
Date: Wednesday, 15 October 2025 at 14:13
To: dev 
Subject: Re: [DISCUSS] Pilot program of an officially supported backport branch
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments

1.) Should we have a mechanism to backport CEP-37, Java 21, and things like 
them, that do not introduce messaging or on-disk version changes?
Yes (though we already agreed to JDK21 on another discussion separately)

2.) Where should those backports happen? (An existing major version branch/a 
new branch/it depends on the feature)
cassandra-5.1 now, on latest GA once we release one under that contract

3.) If a new branch for backports is created, what existing major release 
branch should it be based on? (4.1/5.0/trunk, which is currently on track to be 
a 6.0)
cassandra-5.0

4.) If a new branch is introduced, what should be the fate of cassandra-4.0? 
(make unsupported when the new branch releases/keep until 6.0 releases)
EOL when new branch is cut, but don't EOL 4.1 when 6.0 hits. Get to new cadence 
on next backport line (see above).

On Tue, Oct 14, 2025, at 3:23 PM, Caleb Rackliffe wrote:
I'll go ahead and cast a ballot along the lines of what I posted earlier:

> 1.) Should we have a mechanism to backport CEP-37, Java 21, and things like 
> them, that do not introduce messaging or on-disk version changes?

Yes

> 2.) Where should those backports happen? (An existing major version branch/a 
> new branch/it depends on the feature)

Either cassandra-5.0 or a new cassandra-5.1 (based on the former, equivalent 
for upgrade purposes).

> 3.) If a new branch for backports is created, what existing major release 
> branch should it be based on? (4.1/5.0/trunk, which is currently on track to 
> be a 6.0)

cassandra-5.0 (Anything earlier encourages stagnation.)

> 4.) If a new branch is introduced, what should be the fate of cassandra-4.0? 
> (make unsupported when the new branch releases/keep until 6.0 releases)

cassandra-4.0 becomes unsupported when cassandra-5.1 (if we go that direction) 
is released

On Tue, Oct 14, 2025 at 1:23 PM Jaydeep Chovatia 
mailto:[email protected]>> wrote:
>Regarding the JDK 21 support backport mentioned in the thread, is it really 
>the case even after we voted to backport support for new JDK versions here?: 
>https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9<https://urldefense.com/v3/__https:/lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9__;!!Nhn8V6BzJA!VLMnYnrkQuP2_rbDEBHcD_-N84xP0B29YQKfxs1R0qTdk4HOXI6V8-9kd1h46kqW93TvG6thn1oCezjWKSlJvhuCBg$>
> ?

First, thank you for bringing the historical JDK ML thread—I respect and 
appreciate the context and decisions captured in the JDK ML thread.

On JDK version support, could we take a particularly careful, data-informed 
approach? My (possibly incomplete) understanding is that most organizations 
have moved beyond JDK 11, with Cassandra being an exception. That can put 
operators in a difficult position internally and, at times, create perception 
issues for Cassandra—e.g., “if most of our stack has moved off JDK 11, why 
can’t Cassandra?” This is precisely the kind of discussion we need to have when 
deciding whether to backport any features to stable GA releases or not.

Jaydeep

On Tue, Oct 14, 2025 at 7:54 AM Dmitry Konstantinov 
mailto:[email protected]>> wrote:
Regarding the JDK 21 support backport mentioned in the thread, is it really the 
case even after we voted to backport support for new JDK versions here?: 
https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9<https://urldefense.com/v3/__https:/lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9__;!!Nhn8V6BzJA!VLMnYnrkQuP2_rbDEBHcD_-N84xP0B29YQKfxs1R0qTdk4HOXI6V8-9kd1h46kqW93TvG6thn1oCezjWKSlJvhuCBg$>
 ?

On Tue, 14 Oct 2025 at 02:51, Jaydeep Chovatia 
mailto:[email protected]>> wrote:
>@Jaydeep Chovatia, coul

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

Hi Dinesh,

thanks for reassuring that this branch would be really just for crucial
functionality where benefits justify the backport. I would be more willing
to entertain that idea but I still think that once people see 5.1 is up
they will want to support their case and there will be a lot of pressure to
backport this and that. Not all CEPs / features will make it. We need to be
very selective. There will be a lot of "massaging" around what can go in
and what not and the expectations would need to be set from the very
beginning and followed.

However, I am not still quite sure how that would work in general, reading
Josh email here:

"The branch would selectively accept non‑disruptive improvements that meet
criteria we define together."

Once people are on 5.1, they will want to have all the bug fixes in
there as well. So instead of merging from 4.0 to 4.1, 5.0 and trunk, we
will be doing 4.0. 4.1, 5.0, 5.1 and trunk?

If the answer is yes, then we will have just another branch we need to
fully maintain.

If the answer is no, as in we will skip 5.1 on merges from 4.0 to trunk,
then I think this will be met with disappointment and questions as to why
we are not patching 5.1 as well.

Basically we go all in and maintain 5.1 with all the patches from lower
branches or we just maintain and backport important features but then ...
who is going to use it like that - without receiving bug fixes.



On Wed, Oct 8, 2025 at 9:46 AM Dinesh Joshi  wrote:

> Stefan, Sam – your concerns are absolutely valid and have come up in
> various discussions.
>
> Here's the reality though – many large operators of Cassandra are
> maintaining backports of various features. The proposal here is to try and
> allow these contributors to maintain them in the community instead of
> internally. This is a limited time pilot to see if this model could work.
>
> When we "open the flood gates" then the existence of a backporting branch
>> will be the justification of anything they want to see there because they
>> do not want to upgrade.
>
>
> Stefan — nobody is talking about “opening the floodgates” here. The
> expectation is that small, self contained features could be back ported on
> a case by case basis. Let’s engage on the criteria that makes sense.
>
> On the subject of avoiding backports and using it as a tool to “force”
> people to upgrade, I’d like to point out that if upgrades were easier we
> would not be having this discussion. The simple fact is that upgrades are
> not easy and they are riskier than maintaining backports hence we see this
> pattern.
>
> If the community gets together and makes upgrades easier we will likely
> not have a need for backports.
>
> My suggestion is to engage with “how” this pilot would look like to shape
> it. It is a limited time experiment that might benefit the community. A
> number of contributors have shown interest so ideally we should be open to
> trying it out.
>
>>
> On Wed, Oct 8, 2025 at 12:12 AM Sam Tunnicliffe  wrote:
>
>> I second Štefan's concerns here. The proposal reduces the incentive to
>> upgrade or even test trunk, meaning that the things users want to avoid
>> (features etc, but also just refactorings/re-implementations) because they
>> are as-yet "untrusted" or "unqualified" remain that way for longer. This
>> feels pretty antithetical to the direction we've been aiming to travel in,
>> toward more regular release cycles.
>>
>>
>> > On 8 Oct 2025, at 06:41, Štefan Miklošovič 
>> wrote:
>> >
>> > This is indeed an interesting idea but please let me share my point of
>> view and somehow different opinion on that.
>> >
>> > I share the questions with Jeff and Jeremiah a lot. I see it similarly
>> and they got the point.
>> >
>> > Before 5.0 was out, we had quite a situation where we officially had to
>> take care of 3.0, 3.11, 4.0 and 4.1 at the same time. If a bug was found,
>> we had to patch 5 branches at once (trunk as well). That meant 5 CI jobs.
>> The patching was an endeavour spanning multiple days, realistically. Once
>> 5.0 got out, we officially discontinued 3.0 and 3.11. But what I have been
>> experiencing was that this information about not supporting 3.0 / 3.11 was
>> spreading very slowly among people / customers and I / we had to repeatedly
>> explain to everybody that yes, 3.0 and 3.11 and done. What are they? Done?
>> Yes, done. 3.0 and 3.11 are finished. Finished you say? That means no
>> patches? Yes, no patches. Aha right ... For real? ... you got it. People
>> had to internalize that it is just not going to happen.
>> >
>> > When we "open the flood gates" then the existence of a backporting
>> branch will be the justification of anything they want to see there because
>> they do not want to upgrade. Instead of us working towards a more smooth
>> upgrade we are burying ourselves with older stuff. That slows adoption of
>> new majors a lot. People will not be forced to, there will be way less
>> incentive to do that when all the important goodies are backpo

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

To respond to some of the other points and throw my perspective into the mix:

> Release engineering for a branch is nearly a full-time job.
While release management is a burden (and one we've had a hard time resourcing 
for years), I don't see it as being nearly a full-time job per branch. We also 
have contributors willing to step forward and take on this extra work and 
plenty of opportunity for automation on both release preparation and validation 
that would lower that burden further.

> Unofficial branches will miss correctness and compatibility fixes unless 
> their maintenance is made a burden for all committers.
Both proposals (backport to 5.0, support a 5.1 that accepts backport) would be 
considered official during the pilot. Bugfixes that are 5.0 or older would have 
1 more branch they needed to apply to and merge through.

> – The upgrade matrix becomes more complicated. As features are backported... 
> these upgrade paths will be untested and unexercised.
I agree the matrix would become more complicated but disagree that they would 
be untested and unexercised. I also think the marginal increase in complexity 
is worth taking on for the expected benefits.

For example, with the "cassandra-5.1-backport" branch, we could support:
 • 4.1-5.0
 • 5.0-6.0
 • (new) 5.0-5.1-6.0

This would add 2 new paths to test and add one backport-branch-specific 
constraint (must go through 5.0 to get to 5.1). Any protocol changes in the 
backport branch would need to be validated *from *5.0 and *to *6.0, but 
otherwise not increase the surface area of breakage.

Those types of changes would already need to be verified in the current status 
quo in the 5.0-6.0 path; introducing a branch in the middle that received a 
backport would involve validating that same functional change from 5.0-5.1 as 
from 5.0-6.0 prior, just in whatever differing context might be on that branch.

> – There’s an assumption in this thread that backports are easy to pick up.
I see this discussion as an exploration on how skilled contributors and 
committers can deduplicate their work on private forks, bring those forks 
closer to upstream, and make certain new features available to end users 
earlier. I haven't read anything as implying backporting is easy.

> – Backports branches don’t solve the “some people run forks” problem.
I see this a bit differently; it doesn't "solve" the problem (I don't 
personally see this as a problem to be solved fwiw), but it does bring those 
forks much closer to upstream and move engineering effort that would otherwise 
be on private forks into the public space benefiting everyone.

> – Backports branches don’t solve the user community adoption problem either, 
> unless we’re also publishing per-OS packages, Maven artifacts, etc.
I agree with you that we have a "time to new release" adoption problem broadly 
but I don't see this thread as attempting to address that; do we think 
providing a middle-ground release between frozen GA and feature-dense higher 
risk trunk would worsen adoption?

---

I think a follow-up discussion about how we can enable and encourage users to 
test trunk or run releases cut from it (alphas cut monthly or quarterly) would 
be a great use of our time and energy.

I also think it would be valuable to have a follow up discussion about how we 
can change our engineering practices to make GA releases less disruptive for 
users to transition onto, allow users to incrementally validate new optional 
features, and roll back to older releases with confidence in the event of 
defects (see prior email).


On Sun, Oct 12, 2025, at 12:03 PM, [email protected] wrote:
> I don’t think we have consensus on this thread, but it feels like some are 
> pushing forward as if we do (“If everybody is generally onboard with the 
> proposal, we can start getting into the details of the logistics…,” followed 
> by discussion of logistics).
> 
> The thread also contains multiple different proposals: new feature backports 
> branches, liberalizing feature backports to stable releases, cutting 5.1 now, 
> or stay the course.
> 
> I don’t support creation of new backports branches, but will keep my thoughts 
> brief since there’s a lot of discussion:
> 
> – The CI burden of existing branches is really high. Either new branches are 
> treated as first-class and impose stability burdens on committers, or they 
> fall into disrepair and are unsuitable for releases. Release engineering for 
> a branch is nearly a full-time job.
> – Unofficial branches will miss correctness and compatibility fixes unless 
> their maintenance is made a burden for all committers. If not, they’ll be 
> buggier and more prone to data loss than trunk.
> – The upgrade matrix becomes more complicated. As features are backported, 
> any change affecting internode messaging, config properties, etc. becomes a 
> potential compatibility breakage on upgrade, and these upgrade paths will be 
> untested and unexercised.
> – There’s an assum

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

2025-10-18 Thread Runtian Liu

Thanks Josh,

I strongly support this proposal. I think having a community-maintained
backport branch like cassandra-5.1 would greatly reduce duplicated efforts
and make it much easier for operators to adopt important improvements
without maintaining separate forks. This can really help align the
community’s energy and accelerate the adoption of stable, well-tested
features.

I do have a couple of questions to better understand how this would work in
practice:

   1.

   What will be the *criteria to determine whether a feature is considered
   “non-disruptive”* and eligible for inclusion?
   2.

   How will the *backport process* be initiated? For instance, should it be
   started by the contributor of the original feature, or can anyone
   interested in a particular feature from trunk propose a backport to this
   branch?

Really excited to see this discussion moving forward — I think this could
meaningfully improve how we maintain and evolve Cassandra between major
releases.

Best,
Runtian

On Tue, Oct 7, 2025 at 9:48 AM Francisco Guerrero 
wrote:

> This is a great idea, but like others I do have some additional questions
> about this:
>
> 1. Are we going to be producing artifacts from these branches?
> 2. How many branches are we planning on keeping? Is it one per branch we
> "officially" support?
>
> Best,
> - Francisco
>
> On 2025/10/06 16:03:38 Josh McKenzie wrote:
> > Many large‑scale Cassandra users have had to maintain private feature
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on
> older branches. That duplication adds risk and pulls time away from
> upstream contributions which came up as a pain point in discussion at CoC
> this year.
> >
> > The proposal we came up with: an official, community‑maintained backport
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot
> for a year and then decide if we want to make it official. The branch would
> selectively accept non‑disruptive improvements that meet criteria we define
> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop,
> Kafka, Linux kernel, etc).
> >
> > Benefits include reduced duplicated effort, a safer middle ground
> between trunk and frozen GA releases, faster delivery of vetted features,
> and community energy going to this branch instead of duplicated on private
> forks.
> >
> > If you’re interested in helping curate or maintain this branch - or have
> thoughts on the idea - please reply and voice your thoughts.
> >
> > ~Josh
>

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

2025-10-18 Thread Jeremy Hanna

I like the idea generally as a lot of big users do their own forks with these 
backports anyway and the work already being done would be more shared. 
Realistically there would likely still be forks, just lighter weight forks. One 
risk is that some users may not be comfortable with everything getting 
backported - but if there is trust in the collective effort and people use it, 
it provides a new path to features in contrast to the longer release cycles.

What I've gotten from this proposal for the near future:

4.0, 4.1, 5.0 - keep on with bug/CVE fixes, very conservative improvements, and 
backports
trunk - the pile of new big things until we branch approximately annually - 
includes JDK support updates for the current two LTS versions

NEW: 5.1 - continually adding backports in point releases. Just for a 
theoretical scenario: 5.1.0 includes bigger compaction improvements, security 
features now only in trunk, etc. Releases happen periodically and include 
additional backports. Fast forward to 5.1.3. Something comes along that we 
wouldn't normally backport to 4.0/4.1/5.0 - something like an auto-repair-level 
feature. We would say - hey everyone, this is the backport branch between 
stable and trunk. After some discussion or vetting process, auto-repair comes 
is released with 5.1.4 along with fixes.

Then when 6.0 comes out, there would be a 6.1 with a similar cadence of more 
aggressive backports? At that point the actively supported branches are 4.1, 
5.0, 6.0, and 6.1? At that point what happens with 5.1? Is that no longer 
supported because presumably people on that branch would then move to trunk?

Is that how things would play out according to the proposal?

Thanks,

Jeremy

> On Oct 7, 2025, at 4:00 PM, Ekaterina Dimitrova  wrote:
> 
> What I “hear” here - the difference between backporting patches to older 
> branches and to this backport branch is that backport branch can get a big 
> feature, which is technically higher risk but we will choose non-disruptive 
> ones. 
> So just branch in a fairly good shape? Are we going to produce artifacts 
> indeed? (I second Francisco here)
> I am wondering, what is the signal of having the need for such a branch? Our 
> current release cycle needs revision? (Of course that is independent activity 
> of what we discuss here)
> 
> My guess is that the request for people to maintain such a branch means that 
> this branch won’t be part of the merge strategy and it will be maintained 
> completely separately by volunteers?
> 
> Anyone has some write up that can give us an example how that works for some 
> of the other projects mentioned?
> 
> 
> Thanks,
> Ekaterina
> 
> 
> On Tue, 7 Oct 2025 at 4:53, Jeff Jirsa  > wrote:
>> I have to admit I feel slow because I genuinely can’t tell what’s 
>> functionally different from this vs the existing strategy where we … 
>> selectively write patches for older versions when they’re low risk / high 
>> reward for safety and security 
>> 
>> Setting aside some unspecified nuances you haven’t haven’t defined, what 
>> makes this different from the existing practice of apply selective patches 
>> to old releases so users on old builds have a long term stable release that 
>> gets correctness and security fixes without the risk of new features ?
>> 
>> 
>> 
>> > On Oct 6, 2025, at 9:04 AM, Josh McKenzie > > > wrote:
>> > 
>> > 
>> > Many large‑scale Cassandra users have had to maintain private feature 
>> > back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on 
>> > older branches. That duplication adds risk and pulls time away from 
>> > upstream contributions which came up as a pain point in discussion at CoC 
>> > this year.
>> > 
>> > The proposal we came up with: an official, community‑maintained backport 
>> > branch (e.g. cassandra‑5.1) built on the current GA release that we pilot 
>> > for a year and then decide if we want to make it official. The branch 
>> > would selectively accept non‑disruptive improvements that meet criteria we 
>> > define together. There’s a lot of OSS prior art here (Lucene, httpd, 
>> > Hadoop, Kafka, Linux kernel, etc).
>> > 
>> > Benefits include reduced duplicated effort, a safer middle ground between 
>> > trunk and frozen GA releases, faster delivery of vetted features, and 
>> > community energy going to this branch instead of duplicated on private 
>> > forks.
>> > 
>> > If you’re interested in helping curate or maintain this branch - or have 
>> > thoughts on the idea - please reply and voice your thoughts.
>> > 
>> > ~Josh

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

>What about the following idea: allow community-approved feature backports
to *latest GA* (with a brief window allowing backports to 2 GA branches)
and tier releases as follows:

Makes sense to me. We can define a policy, such as initiating a thread,
similar to "VOTE," and requiring three binding votes and no vetoes, etc.
Initially, we can be more conservative by increasing the binding vote count
from 3 to 5 or even higher; that way, everyone will have a chance to
provide an opinion, yet it remains structured enough so that only
community-intended features get backported.

Jaydeep

On Wed, Oct 8, 2025 at 7:59 AM Štefan Miklošovič 
wrote:

>
>
> On Wed, Oct 8, 2025 at 2:53 PM Josh McKenzie  wrote:
>
>> Thanks for the discussion - it looks like we agree on the problem and the
>> trade‑offs involved.
>>
>> Maintaining an extra branch would add toil: we’d have to merge bug fixes,
>> run CI (including upgrade tests), and extend the already lengthy upstream
>> path. A simpler alternative is to relax our backport restrictions on GA
>> branches.
>>
>
> Yes, this would mean CEP-37 would go to 5.0.x, for example. I do not have
> a problem with that in general, I am just not sure if we can "abuse" a
> patch release for this kind of addition. It would really have to be
> "non-disruptive as much as possible". This would be in line with what Jeff
> / Jeremiah / myself were suggesting as well. We would not need to introduce
> a new branch, upgrade paths would be tested as they are now, bug fixes
> would be added too ...
>
> Looking forward to the opinions of other people.
>
>
>>
>> What about the following idea: allow community-approved feature backports
>> to *latest GA* (with a brief window allowing backports to 2 GA branches)
>> and tier releases as follows:
>>
>> *When a new release is cut:*
>>
>>- New release / Latest GA (6.0): stabilizing (backports accepted)
>>- Middle GA (5.0): backports accepted
>>- Oldest GA (4.1): stable
>>
>> *When the new release stabilizes:*
>>
>>- Latest GA (6.0): backports accepted
>>- Middle GA (5.0): stable
>>- Oldest GA (4.1): stable
>>
>> This approach gives users a clear choice - stable, backport‑enabled, or a
>> temporary stabilizing branch - without adding CI overhead.
>>
>> On Wed, Oct 8, 2025, at 5:42 AM, Štefan Miklošovič wrote:
>>
>> Hi Dinesh,
>>
>> thanks for reassuring that this branch would be really just for crucial
>> functionality where benefits justify the backport. I would be more willing
>> to entertain that idea but I still think that once people see 5.1 is up
>> they will want to support their case and there will be a lot of pressure to
>> backport this and that. Not all CEPs / features will make it. We need to be
>> very selective. There will be a lot of "massaging" around what can go in
>> and what not and the expectations would need to be set from the very
>> beginning and followed.
>>
>> However, I am not still quite sure how that would work in general,
>> reading Josh email here:
>>
>> "The branch would selectively accept non‑disruptive improvements that
>> meet criteria we define together."
>>
>> Once people are on 5.1, they will want to have all the bug fixes in
>> there as well. So instead of merging from 4.0 to 4.1, 5.0 and trunk, we
>> will be doing 4.0. 4.1, 5.0, 5.1 and trunk?
>>
>> If the answer is yes, then we will have just another branch we need to
>> fully maintain.
>>
>> If the answer is no, as in we will skip 5.1 on merges from 4.0 to trunk,
>> then I think this will be met with disappointment and questions as to why
>> we are not patching 5.1 as well.
>>
>> Basically we go all in and maintain 5.1 with all the patches from lower
>> branches or we just maintain and backport important features but then ...
>> who is going to use it like that - without receiving bug fixes.
>>
>>
>>
>> On Wed, Oct 8, 2025 at 9:46 AM Dinesh Joshi  wrote:
>>
>> Stefan, Sam – your concerns are absolutely valid and have come up in
>> various discussions.
>>
>> Here's the reality though – many large operators of Cassandra are
>> maintaining backports of various features. The proposal here is to try and
>> allow these contributors to maintain them in the community instead of
>> internally. This is a limited time pilot to see if this model could work.
>>
>> When we "open the flood gates" then the existence of a backporting branch
>> will be the justification of anything they want to see there because they
>> do not want to upgrade.
>>
>>
>> Stefan — nobody is talking about “opening the floodgates” here. The
>> expectation is that small, self contained features could be back ported on
>> a case by case basis. Let’s engage on the criteria that makes sense.
>>
>> On the subject of avoiding backports and using it as a tool to “force”
>> people to upgrade, I’d like to point out that if upgrades were easier we
>> would not be having this discussion. The simple fact is that upgrades are
>> not easy and they are riskier than maintaining backports hence we see

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

2025-10-18 Thread Aleksey Yeshchenko

If we collectively trust the backported branch enough to run it in production 
at scale, then we might as well have the code in the GA branch.

Tweaking our criteria for inclusion in a GA branch is then what should be 
changed, rather than be seen as immutable and be worked around through 
introduction of even more branches.

As it is, I’m really *not* a big fan of expanding the number of branches we 
support. It’s a rather significant burden for every merge up, and it’s 
release-management burden, too.

> I agree with the sentiment here but think I disagree on the implications. If 
> we have multiple private forks running large scale fleets w/backported 
> features, having that same code on the latest GA branch doesn't unduly 
> jeopardize the stability of that branch. The more we discuss this the more 
> I'm leaning towards "latest GA gets community approved, running in prod, 
> non-disruptive backports" for all the reasons discussed in this thread.


Essentially this ^ (started typing my response before Josh’s email arrived, but 
basically this).

> On 9 Oct 2025, at 13:56, Josh McKenzie  wrote:
> 
>> I agree that anything to help alleviate this situation: without removing the 
>> option of, or jeopardising/softening, the users safe stable "GA" experience; 
>> would be most welcome. 
> I agree with the sentiment here but think I disagree on the implications. If 
> we have multiple private forks running large scale fleets w/backported 
> features, having that same code on the latest GA branch doesn't unduly 
> jeopardize the stability of that branch. The more we discuss this the more 
> I'm leaning towards "latest GA gets community approved, running in prod, 
> non-disruptive backports" for all the reasons discussed in this thread.
> 
>> it should include all features from trunk that we consider to be production 
>> ready
> Again - agree with the sentiment but we'd need to discuss these on a 
> case-by-case basis as a community. There will be a big lift up front to go 
> through the 5.0->trunk gap but once past that should be nice and incremental.
> 
> On Thu, Oct 9, 2025, at 5:00 AM, Marcus Eriksson wrote:
>> I think cutting a 5.1 now makes sense
>> 
>> But it should include all features from trunk that we consider to be 
>> production ready (that includes TCM in my book)
>> 
>> /Marcus
>> 
>> On Thu, Oct 09, 2025 at 12:30:09AM +0200, Mick wrote:
>> > 
>> > It is fantastic to read this Josh, to see an initiative to create a space 
>> > to bring new collaborators and energy into the project.
>> > 
>> > Thank you for bringing it forward, representing those down-stream-fork 
>> > users.  I'm reading this as true to the open source ethos of "scratch your 
>> > itch", and I see the value of letting meritocracy do its thing here.  Some 
>> > (not all) of the objections and concerns I've read seem to be missing the 
>> > point of what people are saying they are already doing– and that if we 
>> > create space and process for them they can do that work lighter to the 
>> > benefit of more…
>> > 
>> > FTR, I'm not in favour of softening what goes into 5.0.x (see last 
>> > paragraph for more), I do believe (despite a long write-up) it can be 
>> > trivial to introduce a cassandra-5.1 branch for the pilot, but it would 
>> > require some up front agreements.
>> > 
>> > My thoughts to this so far…
>> > 
>> >  - Distinction from the stable branch (Jeff, Stefan): this seems to be 
>> > about back porting features from trunk, something we forbid/frown upon 
>> > doing as it jeopardises our stable branch.  If folk are going to extra 
>> > effort to back port into private forks specific features for the value 
>> > they provide: despite the risk (and extra effort in private QA-ing) the 
>> > private back port against safety and security; and they want to pilot a 
>> > way to collaborate together to reduce that effort in the project then we 
>> > should be supportive of that.  Nor should we hijack our existing stable 
>> > branches.   So yeah, I do see a clear distinction here.
>> > 
>> >  - We would need to be careful about what gets back ported (Isaac, Stefan, 
>> > Runtian).  IMHO this cannot be about "this feature should…" but rather 
>> > sticking to the pilot's specific value-add and litmus test: folk are 
>> > running this feature in production in their private fork already.  So IMHO 
>> > this should also exclude any downstream vendor saying "we have customers 
>> > asking for this feature so we want to back port it" as I would suggest 
>> > that's our slippery slope (this is different to a vendor saying "we are 
>> > already running this downstream").  This debunks the floodgates concern– 
>> > this is not about what users or vendors "want".  This is about what 
>> > downstream developers a) are already running in production, and b) are 
>> > themselves willing to step forward into the community and do the work in 
>> > the pilot.  We should also be explicit about the things we cannot accept 
>> > back ports of

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

> What one team considers ready and low risk, another team begs not to be 
> included. I suspect if there was really, truly a shared understanding of 
> “this is back port ready, low risk, ready to run”, we could just put it into 
> the existing branches (with a “yes this is a feature, but it’s a feature we 
> all trust” discussion)?
I don't think we've tested this enough to know. We've drawn a hard line in the 
sand of "no backports of improvements or new features" as one of our many 
efforts at stabilizing the database; I haven't seen anyone make a strong 
argument against back-porting JDK21 support or CEP-37 for instance. So we 
haven't had these debates in a structured fashion yet; you might be right, but 
there may be ways we can mitigate that and move that needle.

My personal .02: I'd be comfortable with us allowing select backports to GA 
branches if we had some clear community consensus on the dev ML. I don't think 
it'd destabilize the DB if we were judicious about what we chose, and I believe 
on the whole users would prefer that balance vs. multi-year waits for new 
releases, new functionality, and all the qualification burden that comes from 
how "fat" our releases are.

If the requirements were clear and agreed upon, something like:
 1. Someone must be running it in prod on >= N clusters for >= M time (TBD) and 
vouch for their experience with it
 2. Must be disabled by default / feature flagged
 3. Must be able to easily and gracefully disable the feature w/out breaking 
your cluster, taking downtime, or otherwise impacting prod
 4. Must be agreed upon by majority of PMC roll-called quorum on dev [DISCUSS] 
/ [VOTE] thread for feature
 5. Must be clearly and thoroughly documented (user, operator, dev docs in 
code-base and on website)
I'd personally be happy with that.

(I like your "cassandra-5.1, only add those 2 features" idea too Stefan but 
feel like there's value in exploring the "why don't we backport to GA?" 
question a bit further in isolation)

On Mon, Oct 13, 2025, at 2:13 PM, Štefan Miklošovič wrote:
> What about this: do a proper 5.1 branch with everything (pipelines, release 
> ...) but put there only Java 21 support and CEP-37?
> 
> Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
> intact, 5.1 would be a branch we try this new model in, learn the lessons 
> from it. When we support Java 21 and CEP-37 as only two changes and nothing 
> else, it will already address Java 21 / unsupported Java 17 concerns and it 
> would bring a lot of relief to people trying to transition to 6.0 eventually 
> and they would have some time to prepare for that. Then, in 6.0, TCM / Accord 
> would be production ready waiting for them to migrate to, while they would 
> already be on Java 21 + repairs.
> 
> So for a while we would have 
> 
> 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> 
> Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be 
> 
> 5.0 -> 5.1 -> 6.0 -> trunk
> 
> Then we can do 6.1 branch and we will have some experience of what worked / 
> did not and we will be more ready to backport more or we will just abandon 
> this altogether.
> 
> My idea is to just do something quick yet already beneficial. If we backport 
> only Java 21 and CEP-37 then upgrade paths will be pretty smooth, nothing new 
> will be there to cause any friction.
> 
> As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 -> 5.1 
> would be very easy, in majority of cases just clean merges up.
> 
> The only overhead is CI but we have pre-ci too which we can leverage so ...
> 
> I would be more open to this if we agreed that the scope of the backporting 
> on this initial pilot will be limited to a minimum of features and nothing 
> else. Then we can just reflect on what we did.
> 
> On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
>> 
>> 
>> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  wrote:
>> > 
>> > To respond to some of the other points and throw my perspective into the 
>> > mix:
>> > 
>> >> Release engineering for a branch is nearly a full-time job.
>> > While release management is a burden (and one we've had a hard time 
>> > resourcing for years), I don't see it as being nearly a full-time job per 
>> > branch. We also have contributors willing to step forward and take on this 
>> > extra work and plenty of opportunity for automation on both release 
>> > preparation and validation that would lower that burden further.
>> > 
>> >> Unofficial branches will miss correctness and compatibility fixes unless 
>> >> their maintenance is made a burden for all committers.
>> > Both proposals (backport to 5.0, support a 5.1 that accepts backport) 
>> > would be considered official during the pilot. Bugfixes that are 5.0 or 
>> > older would have 1 more branch they needed to apply to and merge through.
>> > 
>> 
>> I see the word unofficial used too many times. There’s no such thing as 
>> unofficial. If it’s merged by committers and voted on for release by the 
>>

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

On Sat, Oct 11, 2025 at 4:48 AM Josh McKenzie  wrote:

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

I have a personal preference for cassandra-5.0-backports instead of
cassandra-5.1. The naming is clear, unambiguous and communicates the
_intent_ without having to look up documentation.

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

My preference is to have `cassandra-5.0-stable` and
`cassandra-5.0-backports` artifact names.


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

+1


> 5. What is the proposed time duration of the pilot?
>
> 12 months, with quarterly [DISCUSS] retro check-ins on dev@.
>

+1

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

Totally in support of this idea. As we know, CEP-37 has already been merged
into the trunk. However, many individuals who are not on the trunk have
been using the CEP-37 work on 4.1. Therefore, I have been maintaining a
private fork (
https://github.com/jaydeepkumar1984/cassandra/tree/auto_repair_v2_on_4_1),
which is quite painful to manage. I have more 4.1 users inquiring about
using this, as they are now aware that the CEP-37 4.1 work is already in
use by Cassandra operators and is pretty stable, and they are already on
4.1. So more and more folks are going to rely on my private fork, which is
not a great idea either.

I am in favor of officially supporting these features backport. Of course,
we collectively vote on which features to backport and which ones not to.

Jaydeep

On Mon, Oct 6, 2025 at 11:35 AM Isaac Reath  wrote:

> I’m in favor of this idea for all of the reasons Josh mentioned and I’m
> happy to help out with the curation and maintenance. Consolidating these
> efforts seems like a clear win to anyone who is already managing their own
> fork of backports.
>
> A couple of questions that come to mind:
>
> 1) What is the inclusion criteria for a patch to get backported?
>
> 2) What does the lifecycle of this branch look like? If we use the example
> of a cassandra-5.1 branch, what happens to this branch after 6.0 is GA? I
> think there should be some grace period after the next version is cut where
> this branch is still active, but we probably don't need as long of a
> support model as the "main" (i.e. 4.0, 4.1, 5.0, 6.0) releases.
>
>
> On Mon, Oct 6, 2025 at 1:39 PM Rahul Singh (ANANT) 
> wrote:
>
>> Makes sense. Does this become "LTS" ? or is this something else.
>>
>>
>> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:
>>
>>> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:
>>> Many large‑scale Cassandra users have had to maintain private feature
>>> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on
>>> older branches. That duplication adds risk and pulls time away from
>>> upstream contributions which came up as a pain point in discussion at CoC
>>> this year.
>>> The proposal we came up with: an official, community‑maintained backport
>>> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot
>>> for a year and then decide if we want to make it official. The branch would
>>> selectively accept non‑disruptive improvements that meet criteria we define
>>> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop,
>>> Kafka, Linux kernel, etc).
>>> Benefits include reduced duplicated effort, a safer middle ground
>>> between trunk and frozen GA releases, faster delivery of vetted features,
>>> and community energy going to this branch instead of duplicated on private
>>> forks.
>>> If you’re interested in helping curate or maintain this branch - or have
>>> thoughts on the idea - please reply and voice your thoughts.
>>> ~Josh
>>>
>>
>>
>>

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

I'm trying to keep a running idea of what a voting sequence to terminate
this thread might look like. Right now I've got something like:

1.) Should we have a mechanism to backport CEP-37, Java 21, and things like
them, that do not introduce messaging or on-disk version changes? (Yes/No)
2.) Where should those backports happen? (An existing major version
branch/a new branch/it depends on the feature)
3.) If a new branch for backports is created, what existing major release
branch should it be based on? (4.1/5.0/trunk, which is currently on track
to be a 6.0)

The idea is to start w/ what looks less contentious and narrow. Thoughts?

On Mon, Oct 13, 2025 at 3:46 PM Josh McKenzie  wrote:

> Jeff has a branch...
>
> The proposal is we have a shared "cassandra-N-backport" branch that we
> collectively backport things to. Bugfixes also merge to it.
>
> The upgrade path is something we'll need to discuss; we could selectively
> enforce a requirement that upgrading through the backport branch cannot be
> required and architect our changes and testing accordingly.
>
> re: the verbiage on the original email: on re-read it's definitely
> ambiguous. I meant to refer to the "backport branch official release
> process" as a durable official process we do going forward (i.e. promotion
> from pilot to official), not that the branch itself would not be official.
> Words are hard. =/
>
> On Mon, Oct 13, 2025, at 4:38 PM, Josh McKenzie wrote:
>
> I'd add:
> 3. Bugfixes get merged into this branch and it's part of our merge path
>
> So yes: other contributors doing a bugfix on an older branch would need to
> merge it through the backport branch. In theory the divergence from
> whatever its base branch is should be minimal.
>
> If we EOL'ed 4.0 with release of a backport branch we'd still need to
> maintain a net new branch (in terms of merging bugfixes) if 7.0 fast
> follows.
>
> On Mon, Oct 13, 2025, at 4:22 PM, Patrick McFadin wrote:
>
> What a thread, but a good one.
> I'm going to rewind to the very first email Josh sent. At Community over
> Code, I joking(not joking) had a slide that said "Somebody in 2035 will ask
> for a feature to be backported to 3.x" I want to make sure I got what you
> were proposing Josh, because the conversation has been sub-threading.
>
> 1. Create a branch designated explicitly as a backport. You were calling
> it 5.1, but it could easily exist in 4.x
> 2. Somebody wants to backport a feature, instead of doing it on
> $INTERNAL_FORK, propose it on the ML, +1s and then the backport work is for
> the benefit of everyone in the Cassandra community.
>
> Everything else seems like bikeshedding, but I could be wrong. Please
> correct me.
>
> Patrick
>
> On Mon, Oct 13, 2025 at 12:57 PM Dinesh Joshi  wrote:
>
> The title of this thread is “[DISCUSS] Pilot program of an officially
> supported backport branch”
>
> I want to draw attention to the word _official_. There is nothing
> unofficial about what is being discussed here. I am not sure why is that
> word being thrown around in the thread.
>
> To the PMCs and Committers on this project in this thread - we are talking
> about our project’s governance and the OFFICIAL policy around backports. I
> hope this clarifies what the goal of this thread and discussion is.
>
> There was a prior mentions about this being a branch where backported code
> would live and will be untested. Let me clarify that we’re not talking
> about just a branch. The project will create artifacts and release them.
> Having code living in a repository without being released runs counter to
> ASF’s principles.
>
> Thanks,
>
> Dinesh
>
> On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe 
> wrote:
>
> This sort of has to be about something we’ll do officially as a project,
> or the original post is little more than asking what we think about a
> public fork, which (as bad as it would look for the project) nobody really
> needs approval to do anyway, right?
>
> On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
>
> 
>
> Thank you for the pointer but I did read it.
>
> My point is that this thread seems to have gone from “let’s create a
> branch to electively pull changes into” to “we are retrospectively adding a
> 5.1 branch somewhere between 5.0 and current trunk”, which I think is a
> completely different discussion.
>
> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
>
> I am afraid something like an "enthusiast-driven branch" is not a
> thing. Please read the last email of Jeff, first section.
>
> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
> >
> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Could you elaborate: I was under impression the new branch is going to
> be maintained by a group of enthusiasts. Are we now considering making this
> new branch in the upgrade path? This sounds rather different from the
> original idea of having an officially supported back port branch.
> >
> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
> >
> > What about thi

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

Stefan, Sam – your concerns are absolutely valid and have come up in
various discussions.

Here's the reality though – many large operators of Cassandra are
maintaining backports of various features. The proposal here is to try and
allow these contributors to maintain them in the community instead of
internally. This is a limited time pilot to see if this model could work.

When we "open the flood gates" then the existence of a backporting branch
> will be the justification of anything they want to see there because they
> do not want to upgrade.


Stefan — nobody is talking about “opening the floodgates” here. The
expectation is that small, self contained features could be back ported on
a case by case basis. Let’s engage on the criteria that makes sense.

On the subject of avoiding backports and using it as a tool to “force”
people to upgrade, I’d like to point out that if upgrades were easier we
would not be having this discussion. The simple fact is that upgrades are
not easy and they are riskier than maintaining backports hence we see this
pattern.

If the community gets together and makes upgrades easier we will likely not
have a need for backports.

My suggestion is to engage with “how” this pilot would look like to shape
it. It is a limited time experiment that might benefit the community. A
number of contributors have shown interest so ideally we should be open to
trying it out.

>
On Wed, Oct 8, 2025 at 12:12 AM Sam Tunnicliffe  wrote:

> I second Štefan's concerns here. The proposal reduces the incentive to
> upgrade or even test trunk, meaning that the things users want to avoid
> (features etc, but also just refactorings/re-implementations) because they
> are as-yet "untrusted" or "unqualified" remain that way for longer. This
> feels pretty antithetical to the direction we've been aiming to travel in,
> toward more regular release cycles.
>
>
> > On 8 Oct 2025, at 06:41, Štefan Miklošovič 
> wrote:
> >
> > This is indeed an interesting idea but please let me share my point of
> view and somehow different opinion on that.
> >
> > I share the questions with Jeff and Jeremiah a lot. I see it similarly
> and they got the point.
> >
> > Before 5.0 was out, we had quite a situation where we officially had to
> take care of 3.0, 3.11, 4.0 and 4.1 at the same time. If a bug was found,
> we had to patch 5 branches at once (trunk as well). That meant 5 CI jobs.
> The patching was an endeavour spanning multiple days, realistically. Once
> 5.0 got out, we officially discontinued 3.0 and 3.11. But what I have been
> experiencing was that this information about not supporting 3.0 / 3.11 was
> spreading very slowly among people / customers and I / we had to repeatedly
> explain to everybody that yes, 3.0 and 3.11 and done. What are they? Done?
> Yes, done. 3.0 and 3.11 are finished. Finished you say? That means no
> patches? Yes, no patches. Aha right ... For real? ... you got it. People
> had to internalize that it is just not going to happen.
> >
> > When we "open the flood gates" then the existence of a backporting
> branch will be the justification of anything they want to see there because
> they do not want to upgrade. Instead of us working towards a more smooth
> upgrade we are burying ourselves with older stuff. That slows adoption of
> new majors a lot. People will not be forced to, there will be way less
> incentive to do that when all the important goodies are backported anyway.
> >
> > I see that "the backports would be non-disruptive but potentially higher
> risk". I do not completely understand what this means in practice. Let's
> say CEP-37. Is that disruptive or not? What's the definition of that? To
> me, correct me if I am wrong, is that something is disruptive if I just can
> not turn it off even if I do not want to use it. Does one _have to_ use
> CEP-37 when it is backported? No. They can just turn it off. So what is
> exactly the risk of introducing it to e.g. 5.0.x ?
> >
> > Also, how are upgrades done? People are going to upgrade from 5.0.x to
> 5.1 and then it will be possible to upgrade to 6.0 from 5.1? This would
> need us to make the pipelines, incorporate this new path into upgrade tests
> and so on ... a lot of work.
> >
> > I think that the current policy - "only bug fixes to older branches"
> might be relaxed a bit instead and leverage already existing upgrade paths
> and infrastructure to test it all instead of creating brand new branches we
> need to take care of.
> >
> > Regards
> >
> > On Mon, Oct 6, 2025 at 6:04 PM Josh McKenzie 
> wrote:
> > Many large‑scale Cassandra users have had to maintain private feature
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on
> older branches. That duplication adds risk and pulls time away from
> upstream contributions which came up as a pain point in discussion at CoC
> this year.
> >
> > The proposal we came up with: an official, community‑maintained backport
> branch (e.g. cassandra‑5.1) built on the current

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

2025-10-17 Thread Sam Tunnicliffe

I second Štefan's concerns here. The proposal reduces the incentive to upgrade 
or even test trunk, meaning that the things users want to avoid (features etc, 
but also just refactorings/re-implementations) because they are as-yet 
"untrusted" or "unqualified" remain that way for longer. This feels pretty 
antithetical to the direction we've been aiming to travel in, toward more 
regular release cycles. 


> On 8 Oct 2025, at 06:41, Štefan Miklošovič  wrote:
> 
> This is indeed an interesting idea but please let me share my point of view 
> and somehow different opinion on that.
> 
> I share the questions with Jeff and Jeremiah a lot. I see it similarly and 
> they got the point.
> 
> Before 5.0 was out, we had quite a situation where we officially had to take 
> care of 3.0, 3.11, 4.0 and 4.1 at the same time. If a bug was found, we had 
> to patch 5 branches at once (trunk as well). That meant 5 CI jobs. The 
> patching was an endeavour spanning multiple days, realistically. Once 5.0 got 
> out, we officially discontinued 3.0 and 3.11. But what I have been 
> experiencing was that this information about not supporting 3.0 / 3.11 was 
> spreading very slowly among people / customers and I / we had to repeatedly 
> explain to everybody that yes, 3.0 and 3.11 and done. What are they? Done? 
> Yes, done. 3.0 and 3.11 are finished. Finished you say? That means no 
> patches? Yes, no patches. Aha right ... For real? ... you got it. People had 
> to internalize that it is just not going to happen.
> 
> When we "open the flood gates" then the existence of a backporting branch 
> will be the justification of anything they want to see there because they do 
> not want to upgrade. Instead of us working towards a more smooth upgrade we 
> are burying ourselves with older stuff. That slows adoption of new majors a 
> lot. People will not be forced to, there will be way less incentive to do 
> that when all the important goodies are backported anyway. 
> 
> I see that "the backports would be non-disruptive but potentially higher 
> risk". I do not completely understand what this means in practice. Let's say 
> CEP-37. Is that disruptive or not? What's the definition of that? To me, 
> correct me if I am wrong, is that something is disruptive if I just can not 
> turn it off even if I do not want to use it. Does one _have to_ use CEP-37 
> when it is backported? No. They can just turn it off. So what is exactly the 
> risk of introducing it to e.g. 5.0.x ? 
> 
> Also, how are upgrades done? People are going to upgrade from 5.0.x to 5.1 
> and then it will be possible to upgrade to 6.0 from 5.1? This would need us 
> to make the pipelines, incorporate this new path into upgrade tests and so on 
> ... a lot of work.
> 
> I think that the current policy - "only bug fixes to older branches" might be 
> relaxed a bit instead and leverage already existing upgrade paths and 
> infrastructure to test it all instead of creating brand new branches we need 
> to take care of.
> 
> Regards
> 
> On Mon, Oct 6, 2025 at 6:04 PM Josh McKenzie  wrote:
> Many large‑scale Cassandra users have had to maintain private feature 
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on 
> older branches. That duplication adds risk and pulls time away from upstream 
> contributions which came up as a pain point in discussion at CoC this year.
> 
> The proposal we came up with: an official, community‑maintained backport 
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot for 
> a year and then decide if we want to make it official. The branch would 
> selectively accept non‑disruptive improvements that meet criteria we define 
> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop, Kafka, 
> Linux kernel, etc).
> 
> Benefits include reduced duplicated effort, a safer middle ground between 
> trunk and frozen GA releases, faster delivery of vetted features, and 
> community energy going to this branch instead of duplicated on private forks.
> 
> If you’re interested in helping curate or maintain this branch - or have 
> thoughts on the idea - please reply and voice your thoughts.
> 
> ~Josh

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

2025-10-17 Thread Caleb Rackliffe

If there are already unofficial forks of things like “4.1 + auto-repair”, it’s hard to object too much to codifying them, as long as they don’t introduce new messaging versions or make upgrades to an “official” later release difficult. (I’m assuming we wouldn’t, for example, want a 4.1++ that couldn’t be updated to 5.0?)On Oct 7, 2025, at 4:43 PM, Jeremy Hanna  wrote:I like the idea generally as a lot of big users do their own forks with these backports anyway and the work already being done would be more shared. Realistically there would likely still be forks, just lighter weight forks. One risk is that some users may not be comfortable with everything getting backported - but if there is trust in the collective effort and people use it, it provides a new path to features in contrast to the longer release cycles.What I've gotten from this proposal for the near future:4.0, 4.1, 5.0 - keep on with bug/CVE fixes, very conservative improvements, and backportstrunk - the pile of new big things until we branch approximately annually - includes JDK support updates for the current two LTS versionsNEW: 5.1 - continually adding backports in point releases. Just for a theoretical scenario: 5.1.0 includes bigger compaction improvements, security features now only in trunk, etc. Releases happen periodically and include additional backports. Fast forward to 5.1.3. Something comes along that we wouldn't normally backport to 4.0/4.1/5.0 - something like an auto-repair-level feature. We would say - hey everyone, this is the backport branch between stable and trunk. After some discussion or vetting process, auto-repair comes is released with 5.1.4 along with fixes.Then when 6.0 comes out, there would be a 6.1 with a similar cadence of more aggressive backports? At that point the actively supported branches are 4.1, 5.0, 6.0, and 6.1? At that point what happens with 5.1? Is that no longer supported because presumably people on that branch would then move to trunk?Is that how things would play out according to the proposal?Thanks,JeremyOn Oct 7, 2025, at 4:00 PM, Ekaterina Dimitrova  wrote:What I “hear” here - the difference between backporting patches to older branches and to this backport branch is that backport branch can get a big feature, which is technically higher risk but we will choose non-disruptive ones. So just branch in a fairly good shape? Are we going to produce artifacts indeed? (I second Francisco here)I am wondering, what is the signal of having the need for such a branch? Our current release cycle needs revision? (Of course that is independent activity of what we discuss here)My guess is that the request for people to maintain such a branch means that this branch won’t be part of the merge strategy and it will be maintained completely separately by volunteers?Anyone has some write up that can give us an example how that works for some of the other projects mentioned?Thanks,EkaterinaOn Tue, 7 Oct 2025 at 4:53, Jeff Jirsa  wrote:I have to admit I feel slow because I genuinely can’t tell what’s functionally different from this vs the existing strategy where we … selectively write patches for older versions when they’re low risk / high reward for safety and security 

Setting aside some unspecified nuances you haven’t haven’t defined, what makes this different from the existing practice of apply selective patches to old releases so users on old builds have a long term stable release that gets correctness and security fixes without the risk of new features ?

> On Oct 6, 2025, at 9:04 AM, Josh McKenzie  wrote:
> 
> 
> Many large‑scale Cassandra users have had to maintain private feature back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on older branches. That duplication adds risk and pulls time away from upstream contributions which came up as a pain point in discussion at CoC this year.
> 
> The proposal we came up with: an official, community‑maintained backport branch (e.g. cassandra‑5.1) built on the current GA release that we pilot for a year and then decide if we want to make it official. The branch would selectively accept non‑disruptive improvements that meet criteria we define together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop, Kafka, Linux kernel, etc).
> 
> Benefits include reduced duplicated effort, a safer middle ground between trunk and frozen GA releases, faster delivery of vetted features, and community energy going to this branch instead of duplicated on private forks.
> 
> If you’re interested in helping curate or maintain this branch - or have thoughts on the idea - please reply and voice your thoughts.
> 
> ~Josh

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

2025-10-17 Thread Rahul Singh (ANANT)

Makes sense. Does this become "LTS" ? or is this something else.


On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:

> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:
> Many large‑scale Cassandra users have had to maintain private feature
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on
> older branches. That duplication adds risk and pulls time away from
> upstream contributions which came up as a pain point in discussion at CoC
> this year.
> The proposal we came up with: an official, community‑maintained backport
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot
> for a year and then decide if we want to make it official. The branch would
> selectively accept non‑disruptive improvements that meet criteria we define
> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop,
> Kafka, Linux kernel, etc).
> Benefits include reduced duplicated effort, a safer middle ground between
> trunk and frozen GA releases, faster delivery of vetted features, and
> community energy going to this branch instead of duplicated on private
> forks.
> If you’re interested in helping curate or maintain this branch - or have
> thoughts on the idea - please reply and voice your thoughts.
> ~Josh
>

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

I'd add:
3. Bugfixes get merged into this branch and it's part of our merge path

So yes: other contributors doing a bugfix on an older branch would need to 
merge it through the backport branch. In theory the divergence from whatever 
its base branch is should be minimal.

If we EOL'ed 4.0 with release of a backport branch we'd still need to maintain 
a net new branch (in terms of merging bugfixes) if 7.0 fast follows.

On Mon, Oct 13, 2025, at 4:22 PM, Patrick McFadin wrote:
> What a thread, but a good one. 
> I'm going to rewind to the very first email Josh sent. At Community over 
> Code, I joking(not joking) had a slide that said "Somebody in 2035 will ask 
> for a feature to be backported to 3.x" I want to make sure I got what you 
> were proposing Josh, because the conversation has been sub-threading. 
> 
> 1. Create a branch designated explicitly as a backport. You were calling it 
> 5.1, but it could easily exist in 4.x
> 2. Somebody wants to backport a feature, instead of doing it on 
> $INTERNAL_FORK, propose it on the ML, +1s and then the backport work is for 
> the benefit of everyone in the Cassandra community. 
> 
> Everything else seems like bikeshedding, but I could be wrong. Please correct 
> me. 
> 
> Patrick
> 
> On Mon, Oct 13, 2025 at 12:57 PM Dinesh Joshi  wrote:
>> The title of this thread is “[DISCUSS] Pilot program of an officially 
>> supported backport branch”
>> 
>> I want to draw attention to the word _official_. There is nothing unofficial 
>> about what is being discussed here. I am not sure why is that word being 
>> thrown around in the thread.
>> 
>> To the PMCs and Committers on this project in this thread - we are talking 
>> about our project’s governance and the OFFICIAL policy around backports. I 
>> hope this clarifies what the goal of this thread and discussion is.
>> 
>> There was a prior mentions about this being a branch where backported code 
>> would live and will be untested. Let me clarify that we’re not talking about 
>> just a branch. The project will create artifacts and release them. Having 
>> code living in a repository without being released runs counter to ASF’s 
>> principles.
>> 
>> Thanks,
>> 
>> Dinesh
>> 
>> On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe  
>> wrote:
>>> This sort of has to be about something we’ll do officially as a project, or 
>>> the original post is little more than asking what we think about a public 
>>> fork, which (as bad as it would look for the project) nobody really needs 
>>> approval to do anyway, right?
>>> 
 On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
 
 Thank you for the pointer but I did read it.
 
 My point is that this thread seems to have gone from “let’s create a 
 branch to electively pull changes into” to “we are retrospectively adding 
 a 5.1 branch somewhere between 5.0 and current trunk”, which I think is a 
 completely different discussion.
 
 On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
> I am afraid something like an "enthusiast-driven branch" is not a
> thing. Please read the last email of Jeff, first section.
> 
> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
> >
> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Could you elaborate: I was under impression the new branch is going to 
> > be maintained by a group of enthusiasts. Are we now considering making 
> > this new branch in the upgrade path? This sounds rather different from 
> > the original idea of having an officially supported back port branch.
> >
> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
> >
> > What about this: do a proper 5.1 branch with everything (pipelines, 
> > release ...) but put there only Java 21 support and CEP-37?
> >
> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
> > intact, 5.1 would be a branch we try this new model in, learn the 
> > lessons from it. When we support Java 21 and CEP-37 as only two changes 
> > and nothing else, it will already address Java 21 / unsupported Java 17 
> > concerns and it would bring a lot of relief to people trying to 
> > transition to 6.0 eventually and they would have some time to prepare 
> > for that. Then, in 6.0, TCM / Accord would be production ready waiting 
> > for them to migrate to, while they would already be on Java 21 + 
> > repairs.
> >
> > So for a while we would have
> >
> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
> >
> > 5.0 -> 5.1 -> 6.0 -> trunk
> >
> > Then we can do 6.1 branch and we will have some experience of what 
> > worked / did not and we will be more ready to backport more or we will 
> > just abandon this altogether.
> >
> > My idea is to just do something quick yet already beneficial. If we 
> > backport only Ja

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

2025-10-17 Thread Mick




> If we have multiple private forks running large scale fleets w/backported 
> features, having that same code on the latest GA branch doesn't unduly 
> jeopardize the stability of that branch.


I don't agree with this extrapolation, and believe we have already been burnt 
by it.

Having someone run something in their production does not mean it meets our GA 
standard.
Even fleets of clusters within one company has a homogeneous deployment, and 
often a narrow bound of permitted data models.

It certainly heaps, and can be critically unique feedback in helping us get to 
GA, but it is certainly not alone universal, and that does matter for our 
stable branches and the trillions of possible combinations of configurations 
and data models operators can find themselves with.

I want to repeat my earlier statement:  if we introduce bad bugs a long way 
into a stable branch, e.g. 5.0.18;  that's a really bad look for us and I fear 
will burn operators bad enough that we will lose users over it.

It might be more constructive at this point to go through the examples of what 
folk are now running in production in down-streams and are they initial 
candidates for back-porting.

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

2025-10-17 Thread Mick



It is fantastic to read this Josh, to see an initiative to create a space to 
bring new collaborators and energy into the project.

Thank you for bringing it forward, representing those down-stream-fork users.  
I'm reading this as true to the open source ethos of "scratch your itch", and I 
see the value of letting meritocracy do its thing here.  Some (not all) of the 
objections and concerns I've read seem to be missing the point of what people 
are saying they are already doing– and that if we create space and process for 
them they can do that work lighter to the benefit of more…

FTR, I'm not in favour of softening what goes into 5.0.x (see last paragraph 
for more), I do believe (despite a long write-up) it can be trivial to 
introduce a cassandra-5.1 branch for the pilot, but it would require some up 
front agreements.

My thoughts to this so far…

 - Distinction from the stable branch (Jeff, Stefan): this seems to be about 
back porting features from trunk, something we forbid/frown upon doing as it 
jeopardises our stable branch.  If folk are going to extra effort to back port 
into private forks specific features for the value they provide: despite the 
risk (and extra effort in private QA-ing) the private back port against safety 
and security; and they want to pilot a way to collaborate together to reduce 
that effort in the project then we should be supportive of that.  Nor should we 
hijack our existing stable branches.   So yeah, I do see a clear distinction 
here.

 - We would need to be careful about what gets back ported (Isaac, Stefan, 
Runtian).  IMHO this cannot be about "this feature should…" but rather sticking 
to the pilot's specific value-add and litmus test: folk are running this 
feature in production in their private fork already.  So IMHO this should also 
exclude any downstream vendor saying "we have customers asking for this feature 
so we want to back port it" as I would suggest that's our slippery slope (this 
is different to a vendor saying "we are already running this downstream").  
This debunks the floodgates concern– this is not about what users or vendors 
"want".  This is about what downstream developers a) are already running in 
production, and b) are themselves willing to step forward into the community 
and do the work in the pilot.  We should also be explicit about the things we 
cannot accept back ports of: major protocol/messaging compatibility changes; as 
Caleb points out.

 - Lifecycle (Jeremiah, Isaac, Stefan): i would suggest that 5.1 becomes a 
sibling release branch to 5.0.  So yes, it means post 6.0 GA we have an 
additional release branch to maintain (and forward merge commits) in 
cassandra-5.1, but that it EOLs the same time as 5.0 does.  This is a repeat of 
what we did with 3.0 and 3.11.  I think the overhead of this is minimal– it 
might actually make forward merges easier, breaking up the rebasing to smaller 
incremental steps (which ironically is parallel value of reducing and 
de-risking downstream fork work).   But this is still of course a concern to 
consider (Stefan's point about CI runs particularly bears weight, see below), 
but still I think the question of how long we have to maintain branches is the 
bigger concern.  Also note (Jeremy), the next major release after 6.0 is 7.0.  
Any 6.1 future branch would be a similar back-port of 7.0 dev features that 
users have already started using in a downstream production, given the pilot 
proves to be successful (this is to be evaluated).

 - More branches, more CI pain (Stefan):  yeah, this struck me as a legit 
concern.  We do now have pre-ci.cassandra.apache.org 
 and I really hope that alleviates most of 
the pain here (not just in its availability, but in its accessibility and use 
subsequently improve our CI's pipeline efficiency).  Accepting that might not 
entirely cover it, my suggestion here would be we evaluate whether CI on the 
5.1 is a pre-commit requirement. If a bugfix patch for 5.0 has a pre-commit run 
on 5.0 and trunk: like it would today; I'm ok continuing with that onwards– if 
it gets the pilot up and running.  Seeing the value of the pilot, I'm happy to 
contribute to the work involved in adding the upgrade paths.

 - 5.1 Releases (Francisco):  Is this a requirement of the pilot program ?  
Saying up front we won't be cutting releases is a surefire way to enforce the 
idea this is reserved for downstream devs that solely are looking to 
collaborate together on their back ports.  But maybe that's a bit harsh.  It 
would be fair to state clearly that releases off this branch can be fewer, 
given its intent.  The other question that comes to mind is what QA label would 
5.1.x releases have ? Labelling them as betas is another, but gentler, approach 
to messaging what the pilot is for.  (And we want to still be incentivising 
users to upgrade early and often to the latest GA major release, and to be 
incentivising us to be making the

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

2025-10-17 Thread Isaac Reath

With regard to criteria, I think what Mick mentions where backports are
only considered to be official if they are already running in production (I
think ideally, 5.0 base + the backport if we're discussing 5.1), and what
Francisco mentions regarding feature flags are both must-haves.

With regard to 5.0 becoming the backport branch instead of 5.1, it feels
like we're a bit too far into the 5.0 release to retroactively mark it as
"backports" instead of "stable." If operators have adopted 5.0 widely
thinking that this is the new stable version, and this is after the fact
changed, it could impact user trust, even if the backports don't actually
introduce instability themselves. I would hate to be the operator that just
finished their 5.0 upgrade only to find out that I really should have
stayed on 4.1 or 4.0 if I wanted to stay on the stable release.


On Thu, Oct 9, 2025 at 1:03 PM Francisco Guerrero 
wrote:

> Should we make it a strict requirement that all backported features
> have to have the ability to be feature-flagged, and they should be
> feature-flagged off by default? This will help with the stability of the
> *backport* branch.
>
> Best,
> - Francisco
>
> On 2025/10/09 15:59:52 Josh McKenzie wrote:
> > > if we introduce bad bugs a long way into a stable branch, e.g.
> 5.0.18;  that's a really bad look for us and I fear will burn operators bad
> enough that we will lose users over it.
> > I agree with this statement. The nuance is that it wouldn't be on a
> *stable* branch, it'd be on a *backport* branch. Now - if we don't think
> users will understand the distinction between Stable and Backport, that's a
> reasonable conversation to have for sure. Or if we think going from 5.0.X
> as stable to 5.0.X as backport would be disruptive and break contract.
> >
> > That said, the same requirement of users to understand the distinction
> would hold whether our backport branch was 5.0.X or 5.1.X.
> >
> > On Thu, Oct 9, 2025, at 11:48 AM, Mick wrote:
> > >
> > >
> > > > If we have multiple private forks running large scale fleets
> w/backported features, having that same code on the latest GA branch
> doesn't unduly jeopardize the stability of that branch.
> > >
> > >
> > > I don't agree with this extrapolation, and believe we have already
> been burnt by it.
> > >
> > > Having someone run something in their production does not mean it
> meets our GA standard.
> > > Even fleets of clusters within one company has a homogeneous
> deployment, and often a narrow bound of permitted data models.
> > >
> > > It certainly heaps, and can be critically unique feedback in helping
> us get to GA, but it is certainly not alone universal, and that does matter
> for our stable branches and the trillions of possible combinations of
> configurations and data models operators can find themselves with.
> > >
> > > I want to repeat my earlier statement:  if we introduce bad bugs a
> long way into a stable branch, e.g. 5.0.18;  that's a really bad look for
> us and I fear will burn operators bad enough that we will lose users over
> it.
> > >
> > > It might be more constructive at this point to go through the examples
> of what folk are now running in production in down-streams and are they
> initial candidates for back-porting.
> >
>

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

2025-10-17 Thread Patrick McFadin

What a thread, but a good one.

I'm going to rewind to the very first email Josh sent. At Community over
Code, I joking(not joking) had a slide that said "Somebody in 2035 will ask
for a feature to be backported to 3.x" I want to make sure I got what you
were proposing Josh, because the conversation has been sub-threading.

1. Create a branch designated explicitly as a backport. You were calling it
5.1, but it could easily exist in 4.x
2. Somebody wants to backport a feature, instead of doing it on
$INTERNAL_FORK, propose it on the ML, +1s and then the backport work is for
the benefit of everyone in the Cassandra community.

Everything else seems like bikeshedding, but I could be wrong. Please
correct me.

Patrick

On Mon, Oct 13, 2025 at 12:57 PM Dinesh Joshi  wrote:

> The title of this thread is “[DISCUSS] Pilot program of an officially
> supported backport branch”
>
> I want to draw attention to the word _official_. There is nothing
> unofficial about what is being discussed here. I am not sure why is that
> word being thrown around in the thread.
>
> To the PMCs and Committers on this project in this thread - we are talking
> about our project’s governance and the OFFICIAL policy around backports. I
> hope this clarifies what the goal of this thread and discussion is.
>
> There was a prior mentions about this being a branch where backported code
> would live and will be untested. Let me clarify that we’re not talking
> about just a branch. The project will create artifacts and release them.
> Having code living in a repository without being released runs counter to
> ASF’s principles.
>
> Thanks,
>
> Dinesh
>
> On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe 
> wrote:
>
>> This sort of has to be about something we’ll do officially as a project,
>> or the original post is little more than asking what we think about a
>> public fork, which (as bad as it would look for the project) nobody really
>> needs approval to do anyway, right?
>>
>> On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
>>
>> 
>>
>> Thank you for the pointer but I did read it.
>>
>> My point is that this thread seems to have gone from “let’s create a
>> branch to electively pull changes into” to “we are retrospectively adding a
>> 5.1 branch somewhere between 5.0 and current trunk”, which I think is a
>> completely different discussion.
>>
>> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
>>
>> I am afraid something like an "enthusiast-driven branch" is not a
>> thing. Please read the last email of Jeff, first section.
>>
>> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
>> >
>> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>> >
>> > Could you elaborate: I was under impression the new branch is going to
>> be maintained by a group of enthusiasts. Are we now considering making this
>> new branch in the upgrade path? This sounds rather different from the
>> original idea of having an officially supported back port branch.
>> >
>> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
>> >
>> > What about this: do a proper 5.1 branch with everything (pipelines,
>> release ...) but put there only Java 21 support and CEP-37?
>> >
>> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0
>> intact, 5.1 would be a branch we try this new model in, learn the lessons
>> from it. When we support Java 21 and CEP-37 as only two changes and nothing
>> else, it will already address Java 21 / unsupported Java 17 concerns and it
>> would bring a lot of relief to people trying to transition to 6.0
>> eventually and they would have some time to prepare for that. Then, in 6.0,
>> TCM / Accord would be production ready waiting for them to migrate to,
>> while they would already be on Java 21 + repairs.
>> >
>> > So for a while we would have
>> >
>> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>> >
>> > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
>> >
>> > 5.0 -> 5.1 -> 6.0 -> trunk
>> >
>> > Then we can do 6.1 branch and we will have some experience of what
>> worked / did not and we will be more ready to backport more or we will just
>> abandon this altogether.
>> >
>> > My idea is to just do something quick yet already beneficial. If we
>> backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth,
>> nothing new will be there to cause any friction.
>> >
>> > As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0
>> -> 5.1 would be very easy, in majority of cases just clean merges up.
>> >
>> > The only overhead is CI but we have pre-ci too which we can leverage so
>> ...
>> >
>> > I would be more open to this if we agreed that the scope of the
>> backporting on this initial pilot will be limited to a minimum of features
>> and nothing else. Then we can just reflect on what we did.
>> >
>> > On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
>> >
>> >
>> >
>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie 
>> wrote:
>> > >
>> > > To respond to some of the other points and

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

2025-10-17 Thread Jeff Jirsa

> On Oct 13, 2025, at 7:02 AM, Josh McKenzie  wrote:
> 
> To respond to some of the other points and throw my perspective into the mix:
> 
>> Release engineering for a branch is nearly a full-time job.
> While release management is a burden (and one we've had a hard time 
> resourcing for years), I don't see it as being nearly a full-time job per 
> branch. We also have contributors willing to step forward and take on this 
> extra work and plenty of opportunity for automation on both release 
> preparation and validation that would lower that burden further.
> 
>> Unofficial branches will miss correctness and compatibility fixes unless 
>> their maintenance is made a burden for all committers.
> Both proposals (backport to 5.0, support a 5.1 that accepts backport) would 
> be considered official during the pilot. Bugfixes that are 5.0 or older would 
> have 1 more branch they needed to apply to and merge through.
> 

I see the word unofficial used too many times. There’s no such thing as 
unofficial. If it’s merged by committers and voted on for release by the PMC, 
it’s official. If it’s not, it doesn’t belong in the ASF repos. 

> 
>> – Backports branches don’t solve the “some people run forks” problem.
> I see this a bit differently; it doesn't "solve" the problem (I don't 
> personally see this as a problem to be solved fwiw), but it does bring those 
> forks much closer to upstream and move engineering effort that would 
> otherwise be on private forks into the public space benefiting everyone.

I think you’ve seen at least a few reasons in this thread why the goal and 
proposal may not align. What one team considers ready and low risk, another 
team begs not to be included. I suspect if there was really, truly a shared 
understanding of “this is back port ready, low risk, ready to run”, we could 
just put it into the existing branches (with a “yes this is a feature, but it’s 
a feature we all trust” discussion)?

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

2025-10-17 Thread Štefan Miklošovič

I am afraid something like an "enthusiast-driven branch" is not a
thing. Please read the last email of Jeff, first section.

On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
>
> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>
> Could you elaborate: I was under impression the new branch is going to be 
> maintained by a group of enthusiasts. Are we now considering making this new 
> branch in the upgrade path? This sounds rather different from the original 
> idea of having an officially supported back port branch.
>
> On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
>
> What about this: do a proper 5.1 branch with everything (pipelines, release 
> ...) but put there only Java 21 support and CEP-37?
>
> Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
> intact, 5.1 would be a branch we try this new model in, learn the lessons 
> from it. When we support Java 21 and CEP-37 as only two changes and nothing 
> else, it will already address Java 21 / unsupported Java 17 concerns and it 
> would bring a lot of relief to people trying to transition to 6.0 eventually 
> and they would have some time to prepare for that. Then, in 6.0, TCM / Accord 
> would be production ready waiting for them to migrate to, while they would 
> already be on Java 21 + repairs.
>
> So for a while we would have
>
> 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>
> Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
>
> 5.0 -> 5.1 -> 6.0 -> trunk
>
> Then we can do 6.1 branch and we will have some experience of what worked / 
> did not and we will be more ready to backport more or we will just abandon 
> this altogether.
>
> My idea is to just do something quick yet already beneficial. If we backport 
> only Java 21 and CEP-37 then upgrade paths will be pretty smooth, nothing new 
> will be there to cause any friction.
>
> As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 -> 5.1 
> would be very easy, in majority of cases just clean merges up.
>
> The only overhead is CI but we have pre-ci too which we can leverage so ...
>
> I would be more open to this if we agreed that the scope of the backporting 
> on this initial pilot will be limited to a minimum of features and nothing 
> else. Then we can just reflect on what we did.
>
> On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
>
>
>
> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  wrote:
> >
> > To respond to some of the other points and throw my perspective into the 
> > mix:
> >
> >> Release engineering for a branch is nearly a full-time job.
> > While release management is a burden (and one we've had a hard time 
> > resourcing for years), I don't see it as being nearly a full-time job per 
> > branch. We also have contributors willing to step forward and take on this 
> > extra work and plenty of opportunity for automation on both release 
> > preparation and validation that would lower that burden further.
> >
> >> Unofficial branches will miss correctness and compatibility fixes unless 
> >> their maintenance is made a burden for all committers.
> > Both proposals (backport to 5.0, support a 5.1 that accepts backport) would 
> > be considered official during the pilot. Bugfixes that are 5.0 or older 
> > would have 1 more branch they needed to apply to and merge through.
> >
>
> I see the word unofficial used too many times. There’s no such thing as 
> unofficial. If it’s merged by committers and voted on for release by the PMC, 
> it’s official. If it’s not, it doesn’t belong in the ASF repos.
>
> >
> >> – Backports branches don’t solve the “some people run forks” problem.
> > I see this a bit differently; it doesn't "solve" the problem (I don't 
> > personally see this as a problem to be solved fwiw), but it does bring 
> > those forks much closer to upstream and move engineering effort that would 
> > otherwise be on private forks into the public space benefiting everyone.
>
> I think you’ve seen at least a few reasons in this thread why the goal and 
> proposal may not align. What one team considers ready and low risk, another 
> team begs not to be included. I suspect if there was really, truly a shared 
> understanding of “this is back port ready, low risk, ready to run”, we could 
> just put it into the existing branches (with a “yes this is a feature, but 
> it’s a feature we all trust” discussion)?
>
>

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

2025-10-17 Thread Bernardo Botella

I think this is a great idea (as you know Josh ;-) )

I would love to work on Constraints being back ported 

Regards,
Bernardo

> On Oct 6, 2025, at 12:56 PM, Patrick Lee  wrote:
> 
> 100% in favor and how ever i can be involved here i'm game!  I've been 
> involved with deciding to have our own internal fork for this purpose but 
> there is some hesitation for the same reason that Jaydeep says.  I did early 
> on backport CEP-37 for Cassandra 5 and was running tests before it was merged 
> into trunk but we didn't go beyond that. We have a lot of 4.0 and 5.0 in our 
> fleet as we basically overlooked 4.1. So having things like CEP-37 in a 5..0 
> code base i'm all in! 
> 
> On Mon, Oct 6, 2025 at 1:42 PM Jaydeep Chovatia  > wrote:
>> Totally in support of this idea. As we know, CEP-37 has already been merged 
>> into the trunk. However, many individuals who are not on the trunk have been 
>> using the CEP-37 work on 4.1. Therefore, I have been maintaining a private 
>> fork 
>> (https://github.com/jaydeepkumar1984/cassandra/tree/auto_repair_v2_on_4_1), 
>> which is quite painful to manage. I have more 4.1 users inquiring about 
>> using this, as they are now aware that the CEP-37 4.1 work is already in use 
>> by Cassandra operators and is pretty stable, and they are already on 4.1. So 
>> more and more folks are going to rely on my private fork, which is not a 
>> great idea either.
>> 
>> I am in favor of officially supporting these features backport. Of course, 
>> we collectively vote on which features to backport and which ones not to.
>> 
>> Jaydeep
>> 
>> On Mon, Oct 6, 2025 at 11:35 AM Isaac Reath > > wrote:
>>> I’m in favor of this idea for all of the reasons Josh mentioned and I’m 
>>> happy to help out with the curation and maintenance. Consolidating these 
>>> efforts seems like a clear win to anyone who is already managing their own 
>>> fork of backports.
>>> 
>>> A couple of questions that come to mind:
>>> 
>>> 1) What is the inclusion criteria for a patch to get backported?
>>> 
>>> 2) What does the lifecycle of this branch look like? If we use the example 
>>> of a cassandra-5.1 branch, what happens to this branch after 6.0 is GA? I 
>>> think there should be some grace period after the next version is cut where 
>>> this branch is still active, but we probably don't need as long of a 
>>> support model as the "main" (i.e. 4.0, 4.1, 5.0, 6.0) releases.
>>> 
>>> 
>>> On Mon, Oct 6, 2025 at 1:39 PM Rahul Singh (ANANT) >> > wrote:
 Makes sense. Does this become "LTS" ? or is this something else. 
 
 
 On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:
> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:
> Many large‑scale Cassandra users have had to maintain private feature 
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on 
> older branches. That duplication adds risk and pulls time away from 
> upstream contributions which came up as a pain point in discussion at CoC 
> this year.
> The proposal we came up with: an official, community‑maintained backport 
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot 
> for a year and then decide if we want to make it official. The branch 
> would selectively accept non‑disruptive improvements that meet criteria 
> we define together. There’s a lot of OSS prior art here (Lucene, httpd, 
> Hadoop, Kafka, Linux kernel, etc).
> Benefits include reduced duplicated effort, a safer middle ground between 
> trunk and frozen GA releases, faster delivery of vetted features, and 
> community energy going to this branch instead of duplicated on private 
> forks.
> If you’re interested in helping curate or maintain this branch - or have 
> thoughts on the idea - please reply and voice your thoughts.
> ~Josh

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

2025-10-17 Thread Caleb Rackliffe

The two examples that spawned this thread, JDK 21 support and auto-repair,
seem like exactly the kind of things we would want to (and safely can) port
to mainline cassandra-5.0 to provide a carrot for operators on 4.1 to at
least get closer to (if not actually on) trunk. The benefits of doing that
(with care) seem like they justify having a fallback plan of "downgrade to
the previous 5.0.x patch release" if something goes wrong.

On Sun, Oct 12, 2025 at 2:13 PM Jaydeep Chovatia 
wrote:

> Here is my opinion.
>
> >– Unofficial branches will miss correctness and compatibility fixes
> unless their maintenance is made a burden for all committers. If not,
> they’ll be buggier and more prone to data loss than trunk.
>
> Typically, the backporting effort is handled by the author or co-author of
> a given CEP. As long as they are motivated to pursue the backport, I don’t
> anticipate this being a concern. In most cases, their motivation naturally
> comes from the fact that they are themselves relying on or benefiting from
> the backported version.
>
> >– The upgrade matrix becomes more complicated. As features are
> backported, any change affecting internode messaging, config properties,
> etc. becomes a potential compatibility breakage on upgrade, and these
> upgrade paths will be untested and unexercised.
> >– There’s an assumption in this thread that backports are easy to pick
> up. Backporting is often not straightforward and requires a high degree of
> understanding of the surrounding context, integration points, and what’s
> changed across branches.
>
> As discussed earlier, we should conduct a formal vote on any proposed
> backports and exercise caution with those that alter internal communication
> mechanisms, Gossip protocols, or introduce backward incompatibilities.
> Backports should meet a higher threshold—either by addressing fundamental
> gaps in the database framework or by delivering substantial
> reliability/efficiency improvements. For instance, CEP-37 and JDK 17/21 are
> strong candidates for backporting: the former is essential to maintaining
> data correctness in Cassandra, while the latter has become necessary as
> much of the industry has already transitioned beyond JDK 11.
>
> >– The proposal runs counter to the goal of “people running the database
> and finding + fixing issues.” I happily run trunk, but I don’t want to be
> the only one running trunk if others are committing changes to it.
> Committing changes to trunk then backporting them to releases considered
> “stable” doesn’t produce a more stable database.
> >– Backports branches don’t solve the “some people run forks” problem.
> >– Increasing the user community’s confidence in running new releases of
> the database. A lot of people are reluctant to upgrade, but it’s so much
> safer and easier than since the 2.x/3.x days. We want people to be
> confident running new releases of the database, not clinging to a branch.
> >– Deploying trunk and reporting back. Contributors of new features they’d
> like to backport should deploy and operate trunk. It’s the best way to
> establish confidence and makes Cassandra better for everybody.
>
> I must acknowledge that the upgrade process has come a long way since the
> 2.x and 3.x versions, but there’s still room for improvement. For instance,
> when upgrading to 5.1, a lack of a straightforward rollback path can make
> the process risky. This limitation often slows modernization efforts, as
> teams are understandably hesitant to proceed without a reliable fallback.
> Many businesses around the world run critical workloads on Cassandra, and
> an outage caused by an upgrade would ultimately fall on the decision
> makers—making them cautious about taking such risks.
> This concern is precisely why many decision makers prefer to backport
> features (such as CEP-37, JDK 17/21) and operate on private forks rather
> than upgrade to 5.1. This proposal aims to make their lives easier by
> providing an official and coordinated path for backporting, rather than
> leaving each operator to maintain their own fork. For example, support for
> JDK 17 or 21 on version 4.1 is already a widespread need among operators.
> We should certainly begin a new discussion on how to make our upgrade/new
> versions process safer, so that, in the long run, the need for backporting
> and similar discussions is eliminated.
>
> >– Increasing release velocity. We do need to improve here and I’d be open
> to 5.1.
>
> I am not sure that’s the case. For most decision makers, the primary
> concern isn’t velocity but safety. The key question they ask themselves is,
> ‘What is my fallback plan?’ If that plan appears uncertain or risky, they
> are understandably hesitant to proceed with an upgrade.
>
>
> Jaydeep
>
> On Sun, Oct 12, 2025 at 9:04 AM  wrote:
>
>> I don’t think we have consensus on this thread, but it feels like some
>> are pushing forward as if we do (“If everybody is generally onboard with
>> the proposal, we can start g

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

2025-10-17 Thread 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,BernardoEl oct 11, 2025, a las 4:47 a. m., Josh McKenzie 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 releases5. What is the proposed time duration of the pilot?12 months, with quarterly [DISCUSS] retro check-ins on [email protected] 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 sur

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

> I agree that anything to help alleviate this situation: without removing the 
> option of, or jeopardising/softening, the users safe stable "GA" experience; 
> would be most welcome. 
I agree with the sentiment here but think I disagree on the implications. If we 
have multiple private forks running large scale fleets w/backported features, 
having that same code on the latest GA branch doesn't unduly jeopardize the 
stability of that branch. The more we discuss this the more I'm leaning towards 
"latest GA gets community approved, running in prod, non-disruptive backports" 
for all the reasons discussed in this thread.

> it should include all features from trunk that we consider to be production 
> ready
Again - agree with the sentiment but we'd need to discuss these on a 
case-by-case basis as a community. There will be a big lift up front to go 
through the 5.0->trunk gap but once past that should be nice and incremental.

On Thu, Oct 9, 2025, at 5:00 AM, Marcus Eriksson wrote:
> I think cutting a 5.1 now makes sense
> 
> But it should include all features from trunk that we consider to be 
> production ready (that includes TCM in my book)
> 
> /Marcus
> 
> On Thu, Oct 09, 2025 at 12:30:09AM +0200, Mick wrote:
> > 
> > It is fantastic to read this Josh, to see an initiative to create a space 
> > to bring new collaborators and energy into the project.
> > 
> > Thank you for bringing it forward, representing those down-stream-fork 
> > users.  I'm reading this as true to the open source ethos of "scratch your 
> > itch", and I see the value of letting meritocracy do its thing here.  Some 
> > (not all) of the objections and concerns I've read seem to be missing the 
> > point of what people are saying they are already doing– and that if we 
> > create space and process for them they can do that work lighter to the 
> > benefit of more…
> > 
> > FTR, I'm not in favour of softening what goes into 5.0.x (see last 
> > paragraph for more), I do believe (despite a long write-up) it can be 
> > trivial to introduce a cassandra-5.1 branch for the pilot, but it would 
> > require some up front agreements.
> > 
> > My thoughts to this so far…
> > 
> >  - Distinction from the stable branch (Jeff, Stefan): this seems to be 
> > about back porting features from trunk, something we forbid/frown upon 
> > doing as it jeopardises our stable branch.  If folk are going to extra 
> > effort to back port into private forks specific features for the value they 
> > provide: despite the risk (and extra effort in private QA-ing) the private 
> > back port against safety and security; and they want to pilot a way to 
> > collaborate together to reduce that effort in the project then we should be 
> > supportive of that.  Nor should we hijack our existing stable branches.   
> > So yeah, I do see a clear distinction here.
> > 
> >  - We would need to be careful about what gets back ported (Isaac, Stefan, 
> > Runtian).  IMHO this cannot be about "this feature should…" but rather 
> > sticking to the pilot's specific value-add and litmus test: folk are 
> > running this feature in production in their private fork already.  So IMHO 
> > this should also exclude any downstream vendor saying "we have customers 
> > asking for this feature so we want to back port it" as I would suggest 
> > that's our slippery slope (this is different to a vendor saying "we are 
> > already running this downstream").  This debunks the floodgates concern– 
> > this is not about what users or vendors "want".  This is about what 
> > downstream developers a) are already running in production, and b) are 
> > themselves willing to step forward into the community and do the work in 
> > the pilot.  We should also be explicit about the things we cannot accept 
> > back ports of: major protocol/messaging compatibility changes; as Caleb 
> > points out.
> > 
> >  - Lifecycle (Jeremiah, Isaac, Stefan): i would suggest that 5.1 becomes a 
> > sibling release branch to 5.0.  So yes, it means post 6.0 GA we have an 
> > additional release branch to maintain (and forward merge commits) in 
> > cassandra-5.1, but that it EOLs the same time as 5.0 does.  This is a 
> > repeat of what we did with 3.0 and 3.11.  I think the overhead of this is 
> > minimal– it might actually make forward merges easier, breaking up the 
> > rebasing to smaller incremental steps (which ironically is parallel value 
> > of reducing and de-risking downstream fork work).   But this is still of 
> > course a concern to consider (Stefan's point about CI runs particularly 
> > bears weight, see below), but still I think the question of how long we 
> > have to maintain branches is the bigger concern.  Also note (Jeremy), the 
> > next major release after 6.0 is 7.0.  Any 6.1 future branch would be a 
> > similar back-port of 7.0 dev features that users have already started using 
> > in a downstream production, given the pilot proves to be successful (this 
> > is to be evaluated).
> >

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

2025-10-17 Thread Jeremiah Jordan

I think this is an interesting idea.

I am also wondering what you think the life cycle looks like for such a
branch once 6.0 is released?  Does it continue getting backports from the
new trunk?  Do we start a “6.1” branch and stop maintaining this “5.1”
branch?  Do we maintain both 5.1 and 6.1?

A different idea. For tickets that a large group of people want in 5.0,
does it make more sense to vote to bring those things into the main 5.0
branch? Rather than adding yet another branch to the merge path/maintenance
burden?

I’m not against this. Just want to explore if there are other options to
achieving the goal.

-Jeremiah Jordan

On Mon, Oct 6, 2025 at 5:14 PM Bernardo Botella <
[email protected]> wrote:

> I think this is a great idea (as you know Josh ;-) )
>
> I would love to work on Constraints being back ported
>
> Regards,
> Bernardo
>
>
> On Oct 6, 2025, at 12:56 PM, Patrick Lee 
> wrote:
>
> 100% in favor and how ever i can be involved here i'm game!  I've been
> involved with deciding to have our own internal fork for this purpose but
> there is some hesitation for the same reason that Jaydeep says.  I did
> early on backport CEP-37 for Cassandra 5 and was running tests before it
> was merged into trunk but we didn't go beyond that. We have a lot of 4.0
> and 5.0 in our fleet as we basically overlooked 4.1. So having things like
> CEP-37 in a 5..0 code base i'm all in!
>
> On Mon, Oct 6, 2025 at 1:42 PM Jaydeep Chovatia <
> [email protected]> wrote:
>
>> Totally in support of this idea. As we know, CEP-37 has already been
>> merged into the trunk. However, many individuals who are not on the trunk
>> have been using the CEP-37 work on 4.1. Therefore, I have been maintaining
>> a private fork (
>> https://github.com/jaydeepkumar1984/cassandra/tree/auto_repair_v2_on_4_1),
>> which is quite painful to manage. I have more 4.1 users inquiring about
>> using this, as they are now aware that the CEP-37 4.1 work is already in
>> use by Cassandra operators and is pretty stable, and they are already on
>> 4.1. So more and more folks are going to rely on my private fork, which is
>> not a great idea either.
>>
>> I am in favor of officially supporting these features backport.
>> Of course, we collectively vote on which features to backport and which
>> ones not to.
>>
>> Jaydeep
>>
>> On Mon, Oct 6, 2025 at 11:35 AM Isaac Reath  wrote:
>>
>>> I’m in favor of this idea for all of the reasons Josh mentioned and I’m
>>> happy to help out with the curation and maintenance. Consolidating these
>>> efforts seems like a clear win to anyone who is already managing their own
>>> fork of backports.
>>>
>>> A couple of questions that come to mind:
>>>
>>> 1) What is the inclusion criteria for a patch to get backported?
>>>
>>> 2) What does the lifecycle of this branch look like? If we use the
>>> example of a cassandra-5.1 branch, what happens to this branch after 6.0 is
>>> GA? I think there should be some grace period after the next version is cut
>>> where this branch is still active, but we probably don't need as long of a
>>> support model as the "main" (i.e. 4.0, 4.1, 5.0, 6.0) releases.
>>>
>>>
>>> On Mon, Oct 6, 2025 at 1:39 PM Rahul Singh (ANANT) 
>>> wrote:
>>>
 Makes sense. Does this become "LTS" ? or is this something else.


 On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:

> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote:
> Many large‑scale Cassandra users have had to maintain private feature
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on
> older branches. That duplication adds risk and pulls time away from
> upstream contributions which came up as a pain point in discussion at CoC
> this year.
> The proposal we came up with: an official, community‑maintained
> backport branch (e.g. cassandra‑5.1) built on the current GA release that
> we pilot for a year and then decide if we want to make it official. The
> branch would selectively accept non‑disruptive improvements that meet
> criteria we define together. There’s a lot of OSS prior art here (Lucene,
> httpd, Hadoop, Kafka, Linux kernel, etc).
> Benefits include reduced duplicated effort, a safer middle ground
> between trunk and frozen GA releases, faster delivery of vetted features,
> and community energy going to this branch instead of duplicated on private
> forks.
> If you’re interested in helping curate or maintain this branch - or
> have thoughts on the idea - please reply and voice your thoughts.
> ~Josh
>



>

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

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

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

What about splitting the difference: cassandra-5.1-backport?

> Our codebase, both runtime and test code, is picky about versioning labels, 
> particularly ordering (which is important for upgrade tests).
This comes up consistently when we talk about how we version and cut releases. 
Do you think there'd be value in having a separate conversation about what 
technical limitations we have around this right now, the level of effort to 
make it more flexible, and the benefits we might gain from that? (emphasis on 
separate conversation; don't want to derail this thread. We can take it to dev 
slack tomorrow. :))


On Sun, Oct 12, 2025, at 5:46 AM, Mick wrote:
> 
> 
> > On 11 Oct 2025, at 19:00, Dinesh Joshi  wrote:
> > 
> > On Sat, Oct 11, 2025 at 4:48 AM Josh McKenzie  wrote:
> > 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.
> > 
> > I have a personal preference for cassandra-5.0-backports instead of 
> > cassandra-5.1. The naming is clear, unambiguous and communicates the 
> > _intent_ without having to look up documentation.
> > 
> >> 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.
> > 
> > My preference is to have `cassandra-5.0-stable` and 
> > `cassandra-5.0-backports` artifact names.
> 
> 
> What would these releases be named then ? 
> 
> Our codebase, both runtime and test code, is picky about versioning labels, 
> particularly ordering (which is important for upgrade tests).
> 
> For the sake of simplicity and ease on that reason I'd rather go with the 
> cassandra-5.1 branch, and have any releases always marked as beta, e.g. 
> 5.1.0-beta1, 5.1.0-beta2, 5.1.0-beta3, 5.1.0-beta4, 5.1.0-beta5, etc.   While 
> cassandra-5.1 and 5.1.0-betaX is not as intuitive to the purpose of a 
> dedicated back-port branch, I don't believe it's going to be not obvious to 
> anyone for very long and isn't one of the bigger challenges is organising 
> this pilot to be smooth.   This approach is also taking advantage of an 
> operator's general expectations on versioning numbering (without knowing the 
> C* specifics).  And if later on we decide we would like the back-port 
> releases to come out of beta, it's then easier (IMHO) to do.

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

> It would leave users on the older backport branch stranded and force upgrades 
> however; using the backport branch would be committing to more frequent 
> updates to stay on a supported branch.
Meant to also say: or we'd just have to support multiple backport branches 
w/bugfixes for longer time, which I'm not keen on.

(sorry for the noise on-list)


On Mon, Oct 6, 2025, at 9:34 PM, Josh McKenzie wrote:
> Yeah, we didn't really get into guts of lifecycle. I could see "backport 
> branch goes EOL when latest GA stabilizes" since then moving to a new 
> backport branch should be low risk. It would leave users on the older 
> backport branch stranded and force upgrades however; using the backport 
> branch would be committing to more frequent updates to stay on a supported 
> branch.
> 
>> A different idea. For tickets that a large group of people want in 5.0, does 
>> it make more sense to vote to bring those things into the main 5.0 branch? 
>> Rather than adding yet another branch to the merge path/maintenance burden?
> This doesn't ruffle my feathers.
> 
> 
> On Mon, Oct 6, 2025, at 7:43 PM, Jeremiah Jordan wrote:
>> I think this is an interesting idea.
>> 
>> I am also wondering what you think the life cycle looks like for such a 
>> branch once 6.0 is released?  Does it continue getting backports from the 
>> new trunk?  Do we start a “6.1” branch and stop maintaining this “5.1” 
>> branch?  Do we maintain both 5.1 and 6.1?
>> 
>> A different idea. For tickets that a large group of people want in 5.0, does 
>> it make more sense to vote to bring those things into the main 5.0 branch? 
>> Rather than adding yet another branch to the merge path/maintenance burden?
>> 
>> I’m not against this. Just want to explore if there are other options to 
>> achieving the goal.
>> 
>> -Jeremiah Jordan
>> 
>> On Mon, Oct 6, 2025 at 5:14 PM Bernardo Botella 
>>  wrote:
>>> I think this is a great idea (as you know Josh ;-) )
>>> 
>>> I would love to work on Constraints being back ported 
>>> 
>>> Regards,
>>> Bernardo
>>> 
>>> 
 On Oct 6, 2025, at 12:56 PM, Patrick Lee  wrote:
 
 100% in favor and how ever i can be involved here i'm game!  I've been 
 involved with deciding to have our own internal fork for this purpose but 
 there is some hesitation for the same reason that Jaydeep says.  I did 
 early on backport CEP-37 for Cassandra 5 and was running tests before it 
 was merged into trunk but we didn't go beyond that. We have a lot of 4.0 
 and 5.0 in our fleet as we basically overlooked 4.1. So having things like 
 CEP-37 in a 5..0 code base i'm all in! 
 
 On Mon, Oct 6, 2025 at 1:42 PM Jaydeep Chovatia 
  wrote:
> Totally in support of this idea. As we know, CEP-37 has already been 
> merged into the trunk. However, many individuals who are not on the trunk 
> have been using the CEP-37 work on 4.1. Therefore, I have been 
> maintaining a private fork 
> (https://github.com/jaydeepkumar1984/cassandra/tree/auto_repair_v2_on_4_1),
>  which is quite painful to manage. I have more 4.1 users inquiring about 
> using this, as they are now aware that the CEP-37 4.1 work is already in 
> use by Cassandra operators and is pretty stable, and they are already on 
> 4.1. So more and more folks are going to rely on my private fork, which 
> is not a great idea either.
> 
> I am in favor of officially supporting these features backport. Of 
> course, we collectively vote on which features to backport and which ones 
> not to.
> 
> Jaydeep
> 
> On Mon, Oct 6, 2025 at 11:35 AM Isaac Reath  wrote:
>> I’m in favor of this idea for all of the reasons Josh mentioned and I’m 
>> happy to help out with the curation and maintenance. Consolidating these 
>> efforts seems like a clear win to anyone who is already managing their 
>> own fork of backports.
>> 
>> A couple of questions that come to mind:
>> 
>> 1) What is the inclusion criteria for a patch to get backported?
>> 
>> 2) What does the lifecycle of this branch look like? If we use the 
>> example of a cassandra-5.1 branch, what happens to this branch after 6.0 
>> is GA? I think there should be some grace period after the next version 
>> is cut where this branch is still active, but we probably don't need as 
>> long of a support model as the "main" (i.e. 4.0, 4.1, 5.0, 6.0) releases.
>> 
>> 
>> On Mon, Oct 6, 2025 at 1:39 PM Rahul Singh (ANANT) 
>>  wrote:
>>> Makes sense. Does this become "LTS" ? or is this something else. 
>>> 
>>> 
>>> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie __ wrote:
 On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie __ wrote:
 Many large‑scale Cassandra users have had to maintain private feature 
 back-port forks (e.g., CEP‑37, compaction optimization, etc) for years 
 on older branches. That duplication adds

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

2025-10-17 Thread Jeff Jirsa

I have to admit I feel slow because I genuinely can’t tell what’s functionally 
different from this vs the existing strategy where we … selectively write 
patches for older versions when they’re low risk / high reward for safety and 
security 

Setting aside some unspecified nuances you haven’t haven’t defined, what makes 
this different from the existing practice of apply selective patches to old 
releases so users on old builds have a long term stable release that gets 
correctness and security fixes without the risk of new features ?



> On Oct 6, 2025, at 9:04 AM, Josh McKenzie  wrote:
> 
> 
> Many large‑scale Cassandra users have had to maintain private feature 
> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on 
> older branches. That duplication adds risk and pulls time away from upstream 
> contributions which came up as a pain point in discussion at CoC this year.
> 
> The proposal we came up with: an official, community‑maintained backport 
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot for 
> a year and then decide if we want to make it official. The branch would 
> selectively accept non‑disruptive improvements that meet criteria we define 
> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop, Kafka, 
> Linux kernel, etc).
> 
> Benefits include reduced duplicated effort, a safer middle ground between 
> trunk and frozen GA releases, faster delivery of vetted features, and 
> community energy going to this branch instead of duplicated on private forks.
> 
> If you’re interested in helping curate or maintain this branch - or have 
> thoughts on the idea - please reply and voice your thoughts.
> 
> ~Josh

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

2025-10-17 Thread Štefan Miklošovič

On Wed, Oct 8, 2025 at 2:53 PM Josh McKenzie  wrote:

> Thanks for the discussion - it looks like we agree on the problem and the
> trade‑offs involved.
>
> Maintaining an extra branch would add toil: we’d have to merge bug fixes,
> run CI (including upgrade tests), and extend the already lengthy upstream
> path. A simpler alternative is to relax our backport restrictions on GA
> branches.
>

Yes, this would mean CEP-37 would go to 5.0.x, for example. I do not have a
problem with that in general, I am just not sure if we can "abuse" a patch
release for this kind of addition. It would really have to be
"non-disruptive as much as possible". This would be in line with what Jeff
/ Jeremiah / myself were suggesting as well. We would not need to introduce
a new branch, upgrade paths would be tested as they are now, bug fixes
would be added too ...

Looking forward to the opinions of other people.


>
> What about the following idea: allow community-approved feature backports
> to *latest GA* (with a brief window allowing backports to 2 GA branches)
> and tier releases as follows:
>
> *When a new release is cut:*
>
>- New release / Latest GA (6.0): stabilizing (backports accepted)
>- Middle GA (5.0): backports accepted
>- Oldest GA (4.1): stable
>
> *When the new release stabilizes:*
>
>- Latest GA (6.0): backports accepted
>- Middle GA (5.0): stable
>- Oldest GA (4.1): stable
>
> This approach gives users a clear choice - stable, backport‑enabled, or a
> temporary stabilizing branch - without adding CI overhead.
>
> On Wed, Oct 8, 2025, at 5:42 AM, Štefan Miklošovič wrote:
>
> Hi Dinesh,
>
> thanks for reassuring that this branch would be really just for crucial
> functionality where benefits justify the backport. I would be more willing
> to entertain that idea but I still think that once people see 5.1 is up
> they will want to support their case and there will be a lot of pressure to
> backport this and that. Not all CEPs / features will make it. We need to be
> very selective. There will be a lot of "massaging" around what can go in
> and what not and the expectations would need to be set from the very
> beginning and followed.
>
> However, I am not still quite sure how that would work in general, reading
> Josh email here:
>
> "The branch would selectively accept non‑disruptive improvements that meet
> criteria we define together."
>
> Once people are on 5.1, they will want to have all the bug fixes in
> there as well. So instead of merging from 4.0 to 4.1, 5.0 and trunk, we
> will be doing 4.0. 4.1, 5.0, 5.1 and trunk?
>
> If the answer is yes, then we will have just another branch we need to
> fully maintain.
>
> If the answer is no, as in we will skip 5.1 on merges from 4.0 to trunk,
> then I think this will be met with disappointment and questions as to why
> we are not patching 5.1 as well.
>
> Basically we go all in and maintain 5.1 with all the patches from lower
> branches or we just maintain and backport important features but then ...
> who is going to use it like that - without receiving bug fixes.
>
>
>
> On Wed, Oct 8, 2025 at 9:46 AM Dinesh Joshi  wrote:
>
> Stefan, Sam – your concerns are absolutely valid and have come up in
> various discussions.
>
> Here's the reality though – many large operators of Cassandra are
> maintaining backports of various features. The proposal here is to try and
> allow these contributors to maintain them in the community instead of
> internally. This is a limited time pilot to see if this model could work.
>
> When we "open the flood gates" then the existence of a backporting branch
> will be the justification of anything they want to see there because they
> do not want to upgrade.
>
>
> Stefan — nobody is talking about “opening the floodgates” here. The
> expectation is that small, self contained features could be back ported on
> a case by case basis. Let’s engage on the criteria that makes sense.
>
> On the subject of avoiding backports and using it as a tool to “force”
> people to upgrade, I’d like to point out that if upgrades were easier we
> would not be having this discussion. The simple fact is that upgrades are
> not easy and they are riskier than maintaining backports hence we see this
> pattern.
>
> If the community gets together and makes upgrades easier we will likely
> not have a need for backports.
>
> My suggestion is to engage with “how” this pilot would look like to shape
> it. It is a limited time experiment that might benefit the community. A
> number of contributors have shown interest so ideally we should be open to
> trying it out.
>
>
>
> On Wed, Oct 8, 2025 at 12:12 AM Sam Tunnicliffe  wrote:
>
> I second Štefan's concerns here. The proposal reduces the incentive to
> upgrade or even test trunk, meaning that the things users want to avoid
> (features etc, but also just refactorings/re-implementations) because they
> are as-yet "untrusted" or "unqualified" remain that way for longer. This
> feels pretty antitheti

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

2025-10-17 Thread Caleb Rackliffe

EDIT: "...if something goes wrong *for 5.0.x -> 5.0.y minor upgrades.*"

On Sun, Oct 12, 2025 at 11:17 PM Caleb Rackliffe 
wrote:

> The two examples that spawned this thread, JDK 21 support and auto-repair,
> seem like exactly the kind of things we would want to (and safely can) port
> to mainline cassandra-5.0 to provide a carrot for operators on 4.1 to at
> least get closer to (if not actually on) trunk. The benefits of doing that
> (with care) seem like they justify having a fallback plan of "downgrade to
> the previous 5.0.x patch release" if something goes wrong.
>
> On Sun, Oct 12, 2025 at 2:13 PM Jaydeep Chovatia <
> [email protected]> wrote:
>
>> Here is my opinion.
>>
>> >– Unofficial branches will miss correctness and compatibility fixes
>> unless their maintenance is made a burden for all committers. If not,
>> they’ll be buggier and more prone to data loss than trunk.
>>
>> Typically, the backporting effort is handled by the author or co-author
>> of a given CEP. As long as they are motivated to pursue the backport, I
>> don’t anticipate this being a concern. In most cases, their motivation
>> naturally comes from the fact that they are themselves relying on or
>> benefiting from the backported version.
>>
>> >– The upgrade matrix becomes more complicated. As features are
>> backported, any change affecting internode messaging, config properties,
>> etc. becomes a potential compatibility breakage on upgrade, and these
>> upgrade paths will be untested and unexercised.
>> >– There’s an assumption in this thread that backports are easy to pick
>> up. Backporting is often not straightforward and requires a high degree of
>> understanding of the surrounding context, integration points, and what’s
>> changed across branches.
>>
>> As discussed earlier, we should conduct a formal vote on any proposed
>> backports and exercise caution with those that alter internal communication
>> mechanisms, Gossip protocols, or introduce backward incompatibilities.
>> Backports should meet a higher threshold—either by addressing fundamental
>> gaps in the database framework or by delivering substantial
>> reliability/efficiency improvements. For instance, CEP-37 and JDK 17/21 are
>> strong candidates for backporting: the former is essential to maintaining
>> data correctness in Cassandra, while the latter has become necessary as
>> much of the industry has already transitioned beyond JDK 11.
>>
>> >– The proposal runs counter to the goal of “people running the database
>> and finding + fixing issues.” I happily run trunk, but I don’t want to be
>> the only one running trunk if others are committing changes to it.
>> Committing changes to trunk then backporting them to releases considered
>> “stable” doesn’t produce a more stable database.
>> >– Backports branches don’t solve the “some people run forks” problem.
>> >– Increasing the user community’s confidence in running new releases of
>> the database. A lot of people are reluctant to upgrade, but it’s so much
>> safer and easier than since the 2.x/3.x days. We want people to be
>> confident running new releases of the database, not clinging to a branch.
>> >– Deploying trunk and reporting back. Contributors of new features
>> they’d like to backport should deploy and operate trunk. It’s the best way
>> to establish confidence and makes Cassandra better for everybody.
>>
>> I must acknowledge that the upgrade process has come a long way since the
>> 2.x and 3.x versions, but there’s still room for improvement. For instance,
>> when upgrading to 5.1, a lack of a straightforward rollback path can make
>> the process risky. This limitation often slows modernization efforts, as
>> teams are understandably hesitant to proceed without a reliable fallback.
>> Many businesses around the world run critical workloads on Cassandra, and
>> an outage caused by an upgrade would ultimately fall on the decision
>> makers—making them cautious about taking such risks.
>> This concern is precisely why many decision makers prefer to backport
>> features (such as CEP-37, JDK 17/21) and operate on private forks rather
>> than upgrade to 5.1. This proposal aims to make their lives easier by
>> providing an official and coordinated path for backporting, rather than
>> leaving each operator to maintain their own fork. For example, support for
>> JDK 17 or 21 on version 4.1 is already a widespread need among operators.
>> We should certainly begin a new discussion on how to make our upgrade/new
>> versions process safer, so that, in the long run, the need for backporting
>> and similar discussions is eliminated.
>>
>> >– Increasing release velocity. We do need to improve here and I’d be
>> open to 5.1.
>>
>> I am not sure that’s the case. For most decision makers, the primary
>> concern isn’t velocity but safety. The key question they ask themselves is,
>> ‘What is my fallback plan?’ If that plan appears uncertain or risky, they
>> are understandably hesitant to proceed with an up

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

2025-10-16 Thread Josh McKenzie

.
>  
> I do want to avoid the situation when various people (I already see some) are 
> trying to ask if this and that will be backported. I really want to prevent 
> features be backported extensively. We need to put some reasonable limit on 
> this otherwise we will be experiencing constant nagging of the community why 
> this or that is not backported and potentially severely preventing 6.0 from 
> broader adoption. Plus the nagging might be so strong that after a while 5.1 
> will be beyond recognition and it will be something nobody actually wanted to 
> happen.
>  
> I want this to be part of the vote, what goes in, if we ever go vote on this 
> proposal (we should). Nothing like “we will see”. No, let’s plan 5.1 ahead 
> and just stick to that for the sake of the simplicity and at least some kind 
> of predictability.
>  
> Regards
>  
> *From: *Josh McKenzie 
> *Date: *Wednesday, 15 October 2025 at 14:13
> *To: *dev 
> *Subject: *Re: [DISCUSS] Pilot program of an officially supported backport 
> branch
> *EXTERNAL EMAIL - USE CAUTION when clicking links or attachments*
> 
>> 1.) Should we have a mechanism to backport CEP-37, Java 21, and things like 
>> them, that do not introduce messaging or on-disk version changes?
> Yes (though we already agreed to JDK21 on another discussion separately)
>  
>> 2.) Where should those backports happen? (An existing major version branch/a 
>> new branch/it depends on the feature)
> cassandra-5.1 now, on latest GA once we release one under that contract
>  
>> 3.) If a new branch for backports is created, what existing major release 
>> branch should it be based on? (4.1/5.0/trunk, which is currently on track to 
>> be a 6.0)
> cassandra-5.0
>  
>> 4.) If a new branch is introduced, what should be the fate of cassandra-4.0? 
>> (make unsupported when the new branch releases/keep until 6.0 releases)
> EOL when new branch is cut, but don't EOL 4.1 when 6.0 hits. Get to new 
> cadence on next backport line (see above).
>  
>  
> On Tue, Oct 14, 2025, at 3:23 PM, Caleb Rackliffe wrote:
>> I'll go ahead and cast a ballot along the lines of what I posted earlier:
>>  
>> > 1.) Should we have a mechanism to backport CEP-37, Java 21, and things 
>> > like them, that do not introduce messaging or on-disk version changes?
>>  
>> Yes
>>  
>> > 2.) Where should those backports happen? (An existing major version 
>> > branch/a new branch/it depends on the feature)
>>  
>> Either cassandra-5.0 or a new cassandra-5.1 (based on the former, equivalent 
>> for upgrade purposes).
>>  
>> > 3.) If a new branch for backports is created, what existing major release 
>> > branch should it be based on? (4.1/5.0/trunk, which is currently on track 
>> > to be a 6.0)
>>  
>> cassandra-5.0 (Anything earlier encourages stagnation.)
>>  
>> > 4.) If a new branch is introduced, what should be the fate of 
>> > cassandra-4.0? (make unsupported when the new branch releases/keep until 
>> > 6.0 releases)
>>  
>> cassandra-4.0 becomes unsupported when cassandra-5.1 (if we go that 
>> direction) is released
>>  
>>  
>> On Tue, Oct 14, 2025 at 1:23 PM Jaydeep Chovatia 
>>  wrote:
>>> >Regarding the JDK 21 support backport mentioned in the thread, is it 
>>> >really the case even after we voted to backport support for new JDK 
>>> >versions here?: 
>>> >https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 
>>> ><https://urldefense.com/v3/__https:/lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9__;!!Nhn8V6BzJA!VLMnYnrkQuP2_rbDEBHcD_-N84xP0B29YQKfxs1R0qTdk4HOXI6V8-9kd1h46kqW93TvG6thn1oCezjWKSlJvhuCBg$>
>>> > ?
>>> First, thank you for bringing the historical JDK ML thread—I respect and 
>>> appreciate the context and decisions captured in the JDK ML thread. 
>>> 
>>> On JDK version support, could we take a particularly careful, data-informed 
>>> approach? My (possibly incomplete) understanding is that most organizations 
>>> have moved beyond JDK 11, with Cassandra being an exception. That can put 
>>> operators in a difficult position internally and, at times, create 
>>> perception issues for Cassandra—e.g., “if most of our stack has moved off 
>>> JDK 11, why can’t Cassandra?” This is precisely the kind of discussion we 
>>> need to have when deciding whether to backport any features to stable GA 
>>> releases or not.
>>> 
>>>  
>>> Jaydeep
>>>  
>>> On Tue, Oct 14, 2025 at 7:54 AM Dmitry Ko

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

2025-10-15 Thread Alex Petrov

> (from Josh) If the fear is that a backport branch is going to entrench users 
> prevent them from qualifying 6.0, that's something we can and should hash 
> out. 

While I do not think this is the only argument (Scott has mentioned many very 
important points in email from Oct 12), I do not think this one should be 
overlooked or silenced in the name of brevity. This is an important aspect: 
community fragmentation and working together on new releases. 

I don't mind having JDK fixes back ported to all branches (which was already 
agreed and supported unanimously). But I think we should work together on 
making new release easy to roll out for everyone rather than backport 
(potentially) everything except two major features. 


On Wed, Oct 15, 2025, at 3:55 PM, Josh McKenzie wrote:
>> severely preventing 6.0 from broader adoption
> If we believe people are maintaining backport branches because there's 
> specific reluctance to qualify 6.0 (or other releases like 5.0 for example), 
> maybe we need to have another [DISCUSS] thread on that topic. My hope (and 
> intuition) was and is that it'd be simpler to meet these contributors where 
> they are and where they're asking to contribute energy and effort to the 
> project in a way that'd deduplicate work and bring benefit to the community.
> 
> If the fear is that a backport branch is going to entrench users prevent them 
> from qualifying 6.0, that's something we can and should hash out. But on 
> another thread please, since this one is already *long*. :)
> 
> On Wed, Oct 15, 2025, at 8:24 AM, Miklosovic, Stefan via dev wrote:
>> I want to stress that I would like 5.1 be with strictly limited on 
>> backported features, as I have written in my last email. It should really be 
>> just Java 21 and CEP-37 and that’s it (plus bugfixes).
>>  
>> I do want to avoid the situation when various people (I already see some) 
>> are trying to ask if this and that will be backported. I really want to 
>> prevent features be backported extensively. We need to put some reasonable 
>> limit on this otherwise we will be experiencing constant nagging of the 
>> community why this or that is not backported and potentially severely 
>> preventing 6.0 from broader adoption. Plus the nagging might be so strong 
>> that after a while 5.1 will be beyond recognition and it will be something 
>> nobody actually wanted to happen.
>>  
>> I want this to be part of the vote, what goes in, if we ever go vote on this 
>> proposal (we should). Nothing like “we will see”. No, let’s plan 5.1 ahead 
>> and just stick to that for the sake of the simplicity and at least some kind 
>> of predictability.
>>  
>> Regards
>>  
>> *From: *Josh McKenzie 
>> *Date: *Wednesday, 15 October 2025 at 14:13
>> *To: *dev 
>> *Subject: *Re: [DISCUSS] Pilot program of an officially supported backport 
>> branch
>> *EXTERNAL EMAIL - USE CAUTION when clicking links or attachments*
>> 
>>> 1.) Should we have a mechanism to backport CEP-37, Java 21, and things like 
>>> them, that do not introduce messaging or on-disk version changes?
>> Yes (though we already agreed to JDK21 on another discussion separately)
>>  
>>> 2.) Where should those backports happen? (An existing major version 
>>> branch/a new branch/it depends on the feature)
>> cassandra-5.1 now, on latest GA once we release one under that contract
>>  
>>> 3.) If a new branch for backports is created, what existing major release 
>>> branch should it be based on? (4.1/5.0/trunk, which is currently on track 
>>> to be a 6.0)
>> cassandra-5.0
>>  
>>> 4.) If a new branch is introduced, what should be the fate of 
>>> cassandra-4.0? (make unsupported when the new branch releases/keep until 
>>> 6.0 releases)
>> EOL when new branch is cut, but don't EOL 4.1 when 6.0 hits. Get to new 
>> cadence on next backport line (see above).
>>  
>>  
>> On Tue, Oct 14, 2025, at 3:23 PM, Caleb Rackliffe wrote:
>>> I'll go ahead and cast a ballot along the lines of what I posted earlier:
>>>  
>>> > 1.) Should we have a mechanism to backport CEP-37, Java 21, and things 
>>> > like them, that do not introduce messaging or on-disk version changes?
>>>  
>>> Yes
>>>  
>>> > 2.) Where should those backports happen? (An existing major version 
>>> > branch/a new branch/it depends on the feature)
>>>  
>>> Either cassandra-5.0 or a new cassandra-5.1 (based on the former, 
>>> equivalent for upgrade purposes).
>>>  
>>> > 3.) If

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

2025-10-15 Thread Josh McKenzie

> severely preventing 6.0 from broader adoption
If we believe people are maintaining backport branches because there's specific 
reluctance to qualify 6.0 (or other releases like 5.0 for example), maybe we 
need to have another [DISCUSS] thread on that topic. My hope (and intuition) 
was and is that it'd be simpler to meet these contributors where they are and 
where they're asking to contribute energy and effort to the project in a way 
that'd deduplicate work and bring benefit to the community.

If the fear is that a backport branch is going to entrench users prevent them 
from qualifying 6.0, that's something we can and should hash out. But on 
another thread please, since this one is already *long*. :)

On Wed, Oct 15, 2025, at 8:24 AM, Miklosovic, Stefan via dev wrote:
> I want to stress that I would like 5.1 be with strictly limited on backported 
> features, as I have written in my last email. It should really be just Java 
> 21 and CEP-37 and that’s it (plus bugfixes).
>  
> I do want to avoid the situation when various people (I already see some) are 
> trying to ask if this and that will be backported. I really want to prevent 
> features be backported extensively. We need to put some reasonable limit on 
> this otherwise we will be experiencing constant nagging of the community why 
> this or that is not backported and potentially severely preventing 6.0 from 
> broader adoption. Plus the nagging might be so strong that after a while 5.1 
> will be beyond recognition and it will be something nobody actually wanted to 
> happen.
>  
> I want this to be part of the vote, what goes in, if we ever go vote on this 
> proposal (we should). Nothing like “we will see”. No, let’s plan 5.1 ahead 
> and just stick to that for the sake of the simplicity and at least some kind 
> of predictability.
>  
> Regards
>  
> *From: *Josh McKenzie 
> *Date: *Wednesday, 15 October 2025 at 14:13
> *To: *dev 
> *Subject: *Re: [DISCUSS] Pilot program of an officially supported backport 
> branch
> *EXTERNAL EMAIL - USE CAUTION when clicking links or attachments*
> 
>> 1.) Should we have a mechanism to backport CEP-37, Java 21, and things like 
>> them, that do not introduce messaging or on-disk version changes?
> Yes (though we already agreed to JDK21 on another discussion separately)
>  
>> 2.) Where should those backports happen? (An existing major version branch/a 
>> new branch/it depends on the feature)
> cassandra-5.1 now, on latest GA once we release one under that contract
>  
>> 3.) If a new branch for backports is created, what existing major release 
>> branch should it be based on? (4.1/5.0/trunk, which is currently on track to 
>> be a 6.0)
> cassandra-5.0
>  
>> 4.) If a new branch is introduced, what should be the fate of cassandra-4.0? 
>> (make unsupported when the new branch releases/keep until 6.0 releases)
> EOL when new branch is cut, but don't EOL 4.1 when 6.0 hits. Get to new 
> cadence on next backport line (see above).
>  
>  
> On Tue, Oct 14, 2025, at 3:23 PM, Caleb Rackliffe wrote:
>> I'll go ahead and cast a ballot along the lines of what I posted earlier:
>>  
>> > 1.) Should we have a mechanism to backport CEP-37, Java 21, and things 
>> > like them, that do not introduce messaging or on-disk version changes?
>>  
>> Yes
>>  
>> > 2.) Where should those backports happen? (An existing major version 
>> > branch/a new branch/it depends on the feature)
>>  
>> Either cassandra-5.0 or a new cassandra-5.1 (based on the former, equivalent 
>> for upgrade purposes).
>>  
>> > 3.) If a new branch for backports is created, what existing major release 
>> > branch should it be based on? (4.1/5.0/trunk, which is currently on track 
>> > to be a 6.0)
>>  
>> cassandra-5.0 (Anything earlier encourages stagnation.)
>>  
>> > 4.) If a new branch is introduced, what should be the fate of 
>> > cassandra-4.0? (make unsupported when the new branch releases/keep until 
>> > 6.0 releases)
>>  
>> cassandra-4.0 becomes unsupported when cassandra-5.1 (if we go that 
>> direction) is released
>>  
>>  
>> On Tue, Oct 14, 2025 at 1:23 PM Jaydeep Chovatia 
>>  wrote:
>>> >Regarding the JDK 21 support backport mentioned in the thread, is it 
>>> >really the case even after we voted to backport support for new JDK 
>>> >versions here?: 
>>> >https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 
>>> ><https://urldefense.com/v3/__https:/lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9__;!!Nhn8V6BzJA!VLMnYnrkQuP2_rbDEBHcD_-

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

2025-10-15 Thread Josh McKenzie

> 1.) Should we have a mechanism to backport CEP-37, Java 21, and things like 
> them, that do not introduce messaging or on-disk version changes?
Yes (though we already agreed to JDK21 on another discussion separately)

> 2.) Where should those backports happen? (An existing major version branch/a 
> new branch/it depends on the feature)
cassandra-5.1 now, on latest GA once we release one under that contract

> 3.) If a new branch for backports is created, what existing major release 
> branch should it be based on? (4.1/5.0/trunk, which is currently on track to 
> be a 6.0)
cassandra-5.0

> 4.) If a new branch is introduced, what should be the fate of cassandra-4.0? 
> (make unsupported when the new branch releases/keep until 6.0 releases)
EOL when new branch is cut, but don't EOL 4.1 when 6.0 hits. Get to new cadence 
on next backport line (see above).


On Tue, Oct 14, 2025, at 3:23 PM, Caleb Rackliffe wrote:
> I'll go ahead and cast a ballot along the lines of what I posted earlier:
> 
> > 1.) Should we have a mechanism to backport CEP-37, Java 21, and things like 
> > them, that do not introduce messaging or on-disk version changes?
> 
> Yes
> 
> > 2.) Where should those backports happen? (An existing major version 
> > branch/a new branch/it depends on the feature)
> 
> Either cassandra-5.0 or a new cassandra-5.1 (based on the former, equivalent 
> for upgrade purposes).
> 
> > 3.) If a new branch for backports is created, what existing major release 
> > branch should it be based on? (4.1/5.0/trunk, which is currently on track 
> > to be a 6.0)
> 
> cassandra-5.0 (Anything earlier encourages stagnation.)
> 
> > 4.) If a new branch is introduced, what should be the fate of 
> > cassandra-4.0? (make unsupported when the new branch releases/keep until 
> > 6.0 releases)
> 
> cassandra-4.0 becomes unsupported when cassandra-5.1 (if we go that 
> direction) is released
> 
> 
> On Tue, Oct 14, 2025 at 1:23 PM Jaydeep Chovatia  
> wrote:
>> >Regarding the JDK 21 support backport mentioned in the thread, is it really 
>> >the case even after we voted to backport support for new JDK versions 
>> >here?: https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 ?
>> First, thank you for bringing the historical JDK ML thread—I respect and 
>> appreciate the context and decisions captured in the JDK ML thread. 
>> 
>> On JDK version support, could we take a particularly careful, data-informed 
>> approach? My (possibly incomplete) understanding is that most organizations 
>> have moved beyond JDK 11, with Cassandra being an exception. That can put 
>> operators in a difficult position internally and, at times, create 
>> perception issues for Cassandra—e.g., “if most of our stack has moved off 
>> JDK 11, why can’t Cassandra?” This is precisely the kind of discussion we 
>> need to have when deciding whether to backport any features to stable GA 
>> releases or not.
>> 
>> 
>> Jaydeep
>> 
>> On Tue, Oct 14, 2025 at 7:54 AM Dmitry Konstantinov  
>> wrote:
>>> Regarding the JDK 21 support backport mentioned in the thread, is it really 
>>> the case even after we voted to backport support for new JDK versions 
>>> here?: https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 ?
>>> 
>>> 
>>> On Tue, 14 Oct 2025 at 02:51, Jaydeep Chovatia  
>>> wrote:
 >@Jaydeep Chovatia, could you elaborate on this, since to my best 
 >knowledge there _is_ a straightforward rollback path for the features I 
 >am aware of. You can enable Accord transactions and later disable them, 
 >and you can also migrate back to Gossip from TCM. Both of these 
 >upgrade/downgrade paths are thoroughly tested. If there are other 
 >features that lack downgrade path, please mention them.
 
 _Accord: _I had an opportunity to review Accord briefly, and based on my 
 understanding, this feature appears to be backward compatible during 
 upgrades. I also have a reasonable level of confidence in its rollback 
 capabilities, as this aspect was discussed to some extent in the “CEP-15 
 Update” mailing list thread.
 
 _TCM:_ While I haven’t yet done an in-depth exploration of all its 
 internals, after reviewing the CEP-21 proposal and our informal 
 discussions during Community Over Code, my current impression is that 
 rolling back from 5.1 to 5.0 after enabling TCM might be either highly 
 complex or not feasible. Of course, I could be mistaken here. I really 
 appreciate your clarification that rollback is fully supported and 
 possible. Given that, it might be very valuable to document a detailed 
 rollback plan (if none exists), corresponding rollback test cases (if none 
 exists), and an [UPDATE] thread to help dispel the common perception that 
 TCM lacks backward compatibility.
 
 Jaydeep
 
 
 On Mon, Oct 13, 2025 at 2:04 AM Alex Petrov  wrote:
> __
> > For instance, when upgrading to 5.1, a lack of a straightfo

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

2025-10-14 Thread Jaydeep Chovatia

>Regarding the JDK 21 support backport mentioned in the thread, is it
really the case even after we voted to backport support for new JDK
versions here?:
https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 ?

First, thank you for bringing the historical JDK ML thread—I respect and
appreciate the context and decisions captured in the JDK ML thread.

On JDK version support, could we take a particularly careful, data-informed
approach? My (possibly incomplete) understanding is that most organizations
have moved beyond JDK 11, with Cassandra being an exception. That can put
operators in a difficult position internally and, at times, create
perception issues for Cassandra—e.g., “if most of our stack has moved off
JDK 11, why can’t Cassandra?” This is precisely the kind of discussion we
need to have when deciding whether to backport any features to stable GA
releases or not.

Jaydeep

On Tue, Oct 14, 2025 at 7:54 AM Dmitry Konstantinov 
wrote:

> Regarding the JDK 21 support backport mentioned in the thread, is it
> really the case even after we voted to backport support for new JDK
> versions here?:
> https://lists.apache.org/thread/7640gzjlwo07kjmoyjpt8gq80qk5qhn9 ?
>
>
> On Tue, 14 Oct 2025 at 02:51, Jaydeep Chovatia 
> wrote:
>
>> >@Jaydeep Chovatia, could you elaborate on this, since to my best
>> knowledge there _is_ a straightforward rollback path for the features I
>> am aware of. You can enable Accord transactions and later disable them, and
>> you can also migrate back to Gossip from TCM. Both of these
>> upgrade/downgrade paths are thoroughly tested. If there are other features
>> that lack downgrade path, please mention them.
>>
>> *Accord: *I had an opportunity to review Accord briefly, and based on my
>> understanding, this feature appears to be backward compatible during
>> upgrades. I also have a reasonable level of confidence in its rollback
>> capabilities, as this aspect was discussed to some extent in the “CEP-15
>> Update” mailing list thread.
>>
>> *TCM:* While I haven’t yet done an in-depth exploration of all its
>> internals, after reviewing the CEP-21 proposal and our informal discussions
>> during Community Over Code, my current impression is that rolling back from
>> 5.1 to 5.0 after enabling TCM might be either highly complex or not
>> feasible. Of course, I could be mistaken here. I really appreciate your
>> clarification that rollback is fully supported and possible. Given that, it
>> might be very valuable to document a detailed rollback plan (if none
>> exists), corresponding rollback test cases (if none exists), and an
>> [UPDATE] thread to help dispel the common perception that TCM lacks
>> backward compatibility.
>>
>> Jaydeep
>>
>>
>> On Mon, Oct 13, 2025 at 2:04 AM Alex Petrov  wrote:
>>
>>> > For instance, when upgrading to 5.1, a lack of a straightforward
>>> rollback path can make the process risky.
>>>
>>> @Jaydeep Chovatia, could you elaborate on this, since to my best
>>> knowledge there _is_ a straightforward rollback path for the features I
>>> am aware of. You can enable Accord transactions and later disable them, and
>>> you can also migrate back to Gossip from TCM. Both of these
>>> upgrade/downgrade paths are thoroughly tested. If there are other features
>>> that lack downgrade path, please mention them.
>>>
>>> On Sun, Oct 12, 2025, at 9:12 PM, Jaydeep Chovatia wrote:
>>>
>>> Here is my opinion.
>>>
>>> >– Unofficial branches will miss correctness and compatibility fixes
>>> unless their maintenance is made a burden for all committers. If not,
>>> they’ll be buggier and more prone to data loss than trunk.
>>>
>>> Typically, the backporting effort is handled by the author or co-author
>>> of a given CEP. As long as they are motivated to pursue the backport, I
>>> don’t anticipate this being a concern. In most cases, their motivation
>>> naturally comes from the fact that they are themselves relying on or
>>> benefiting from the backported version.
>>>
>>> >– The upgrade matrix becomes more complicated. As features are
>>> backported, any change affecting internode messaging, config properties,
>>> etc. becomes a potential compatibility breakage on upgrade, and these
>>> upgrade paths will be untested and unexercised.
>>> >– There’s an assumption in this thread that backports are easy to pick
>>> up. Backporting is often not straightforward and requires a high degree of
>>> understanding of the surrounding context, integration points, and what’s
>>> changed across branches.
>>>
>>> As discussed earlier, we should conduct a formal vote on any proposed
>>> backports and exercise caution with those that alter internal communication
>>> mechanisms, Gossip protocols, or introduce backward incompatibilities.
>>> Backports should meet a higher threshold—either by addressing fundamental
>>> gaps in the database framework or by delivering substantial
>>> reliability/efficiency improvements. For instance, CEP-37 and JDK 17/21 are
>>> strong candidates for backp

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

2025-10-13 Thread Caleb Rackliffe

A 5.1 w/ a limited and almost unanimously agreed upon set of backported
capabilities that does not introduce new SSTable, messaging, etc. formats
and moves the support window for bug fixes to 4.1 is something I could
support.

On Mon, Oct 13, 2025 at 1:36 PM Štefan Miklošovič 
wrote:

> > I like your "cassandra-5.1, only add those 2 features" idea too Stefan
> but feel like there's value in exploring the "why don't we backport to GA?"
> question a bit further in isolation
>
> I was thinking about this a lot recently and I just feel uneasy about
> messing up with 5.0.x. I know I was proposing this myself but I do not have
> a problem changing my mind. I don't know ... it just feels wrong to do
> that. Java 21 into a _patch release_? A stable release should be just
> something I literally copy jars over and I am done. I am not completely
> sure the same level of trust might be put into backporting stuff etc.
>
> I know that it is more work but all things considered I think 5.1 with a
> strict limit on features is just the best way forward.
>
> I am not sure we have the luxury of exploring that, we can't make mistakes
> here, we have just one shot at this, basically.
>
> Really on the edge with this one. Really interesting topic indeed.
>
> On Mon, Oct 13, 2025 at 8:28 PM Josh McKenzie 
> wrote:
>
>> What one team considers ready and low risk, another team begs not to be
>> included. I suspect if there was really, truly a shared understanding of
>> “this is back port ready, low risk, ready to run”, we could just put it
>> into the existing branches (with a “yes this is a feature, but it’s a
>> feature we all trust” discussion)?
>>
>> I don't think we've tested this enough to know. We've drawn a hard line
>> in the sand of "no backports of improvements or new features" as one of our
>> many efforts at stabilizing the database; I haven't seen anyone make a
>> strong argument against back-porting JDK21 support or CEP-37 for instance.
>> So we haven't had these debates in a structured fashion yet; you might be
>> right, but there may be ways we can mitigate that and move that needle.
>>
>> My personal .02: I'd be comfortable with us allowing select backports to
>> GA branches if we had some clear community consensus on the dev ML. I don't
>> think it'd destabilize the DB if we were judicious about what we chose, and
>> I believe on the whole users would prefer that balance vs. multi-year waits
>> for new releases, new functionality, and all the qualification burden that
>> comes from how "fat" our releases are.
>>
>> If the requirements were clear and agreed upon, something like:
>>
>>1. Someone must be running it in prod on >= N clusters for >= M time
>>(TBD) and vouch for their experience with it
>>2. Must be disabled by default / feature flagged
>>3. Must be able to easily and gracefully disable the feature w/out
>>breaking your cluster, taking downtime, or otherwise impacting prod
>>4. Must be agreed upon by majority of PMC roll-called quorum on dev
>>[DISCUSS] / [VOTE] thread for feature
>>5. Must be clearly and thoroughly documented (user, operator, dev
>>docs in code-base and on website)
>>
>> I'd personally be happy with that.
>>
>> (I like your "cassandra-5.1, only add those 2 features" idea too Stefan
>> but feel like there's value in exploring the "why don't we backport to GA?"
>> question a bit further in isolation)
>>
>> On Mon, Oct 13, 2025, at 2:13 PM, Štefan Miklošovič wrote:
>>
>> What about this: do a proper 5.1 branch with everything (pipelines,
>> release ...) but put there only Java 21 support and CEP-37?
>>
>> Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0
>> intact, 5.1 would be a branch we try this new model in, learn the lessons
>> from it. When we support Java 21 and CEP-37 as only two changes and nothing
>> else, it will already address Java 21 / unsupported Java 17 concerns and it
>> would bring a lot of relief to people trying to transition to 6.0
>> eventually and they would have some time to prepare for that. Then, in 6.0,
>> TCM / Accord would be production ready waiting for them to migrate to,
>> while they would already be on Java 21 + repairs.
>>
>> So for a while we would have
>>
>> 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>>
>> Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
>>
>> 5.0 -> 5.1 -> 6.0 -> trunk
>>
>> Then we can do 6.1 branch and we will have some experience of what worked
>> / did not and we will be more ready to backport more or we will just
>> abandon this altogether.
>>
>> My idea is to just do something quick yet already beneficial. If we
>> backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth,
>> nothing new will be there to cause any friction.
>>
>> As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 ->
>> 5.1 would be very easy, in majority of cases just clean merges up.
>>
>> The only overhead is CI but we have pre-ci too which we can lever

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

2025-10-13 Thread Josh McKenzie

> Jeff has a branch... 
The proposal is we have a shared "cassandra-N-backport" branch that we 
collectively backport things to. Bugfixes also merge to it.

The upgrade path is something we'll need to discuss; we could selectively 
enforce a requirement that upgrading through the backport branch cannot be 
required and architect our changes and testing accordingly.

re: the verbiage on the original email: on re-read it's definitely ambiguous. I 
meant to refer to the "backport branch official release process" as a durable 
official process we do going forward (i.e. promotion from pilot to official), 
not that the branch itself would not be official. Words are hard. =/

On Mon, Oct 13, 2025, at 4:38 PM, Josh McKenzie wrote:
> I'd add:
> 3. Bugfixes get merged into this branch and it's part of our merge path
> 
> So yes: other contributors doing a bugfix on an older branch would need to 
> merge it through the backport branch. In theory the divergence from whatever 
> its base branch is should be minimal.
> 
> If we EOL'ed 4.0 with release of a backport branch we'd still need to 
> maintain a net new branch (in terms of merging bugfixes) if 7.0 fast follows.
> 
> On Mon, Oct 13, 2025, at 4:22 PM, Patrick McFadin wrote:
>> What a thread, but a good one. 
>> I'm going to rewind to the very first email Josh sent. At Community over 
>> Code, I joking(not joking) had a slide that said "Somebody in 2035 will ask 
>> for a feature to be backported to 3.x" I want to make sure I got what you 
>> were proposing Josh, because the conversation has been sub-threading. 
>> 
>> 1. Create a branch designated explicitly as a backport. You were calling it 
>> 5.1, but it could easily exist in 4.x
>> 2. Somebody wants to backport a feature, instead of doing it on 
>> $INTERNAL_FORK, propose it on the ML, +1s and then the backport work is for 
>> the benefit of everyone in the Cassandra community. 
>> 
>> Everything else seems like bikeshedding, but I could be wrong. Please 
>> correct me. 
>> 
>> Patrick
>> 
>> On Mon, Oct 13, 2025 at 12:57 PM Dinesh Joshi  wrote:
>>> The title of this thread is “[DISCUSS] Pilot program of an officially 
>>> supported backport branch”
>>> 
>>> I want to draw attention to the word _official_. There is nothing 
>>> unofficial about what is being discussed here. I am not sure why is that 
>>> word being thrown around in the thread.
>>> 
>>> To the PMCs and Committers on this project in this thread - we are talking 
>>> about our project’s governance and the OFFICIAL policy around backports. I 
>>> hope this clarifies what the goal of this thread and discussion is.
>>> 
>>> There was a prior mentions about this being a branch where backported code 
>>> would live and will be untested. Let me clarify that we’re not talking 
>>> about just a branch. The project will create artifacts and release them. 
>>> Having code living in a repository without being released runs counter to 
>>> ASF’s principles.
>>> 
>>> Thanks,
>>> 
>>> Dinesh
>>> 
>>> On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe  
>>> wrote:
 This sort of has to be about something we’ll do officially as a project, 
 or the original post is little more than asking what we think about a 
 public fork, which (as bad as it would look for the project) nobody really 
 needs approval to do anyway, right?
 
> On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
> 
> Thank you for the pointer but I did read it.
> 
> My point is that this thread seems to have gone from “let’s create a 
> branch to electively pull changes into” to “we are retrospectively adding 
> a 5.1 branch somewhere between 5.0 and current trunk”, which I think is a 
> completely different discussion.
> 
> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
>> I am afraid something like an "enthusiast-driven branch" is not a
>> thing. Please read the last email of Jeff, first section.
>> 
>> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
>> >
>> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>> >
>> > Could you elaborate: I was under impression the new branch is going to 
>> > be maintained by a group of enthusiasts. Are we now considering making 
>> > this new branch in the upgrade path? This sounds rather different from 
>> > the original idea of having an officially supported back port branch.
>> >
>> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
>> >
>> > What about this: do a proper 5.1 branch with everything (pipelines, 
>> > release ...) but put there only Java 21 support and CEP-37?
>> >
>> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 
>> > 5.0 intact, 5.1 would be a branch we try this new model in, learn the 
>> > lessons from it. When we support Java 21 and CEP-37 as only two 
>> > changes and nothing else, it will already address Java 21 / 
>> > unsupported Java 17 concerns and it wo

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

I don’t think it’s bike shedding: I just debugged too many upgrade issues and 
had to merge an issue to a bunch of branches,  and would like to clarify some 
things. Namely, the following:
 • Will upgrading from 4.0 to 6.0 be possible without going through this branch?
 • Will every commit going to 5.0 go to this branch?
 • Will committers have to run CI to this branch? (Kind of implied if previous 
point is true)
 • Will we add this version to later version’s messaging service, etc.?

On Mon, Oct 13, 2025, at 10:22 PM, Patrick McFadin wrote:
> What a thread, but a good one. 
> I'm going to rewind to the very first email Josh sent. At Community over 
> Code, I joking(not joking) had a slide that said "Somebody in 2035 will ask 
> for a feature to be backported to 3.x" I want to make sure I got what you 
> were proposing Josh, because the conversation has been sub-threading. 
> 
> 1. Create a branch designated explicitly as a backport. You were calling it 
> 5.1, but it could easily exist in 4.x
> 2. Somebody wants to backport a feature, instead of doing it on 
> $INTERNAL_FORK, propose it on the ML, +1s and then the backport work is for 
> the benefit of everyone in the Cassandra community. 
> 
> Everything else seems like bikeshedding, but I could be wrong. Please correct 
> me. 
> 
> Patrick
> 
> On Mon, Oct 13, 2025 at 12:57 PM Dinesh Joshi  wrote:
>> The title of this thread is “[DISCUSS] Pilot program of an officially 
>> supported backport branch”
>> 
>> I want to draw attention to the word _official_. There is nothing unofficial 
>> about what is being discussed here. I am not sure why is that word being 
>> thrown around in the thread.
>> 
>> To the PMCs and Committers on this project in this thread - we are talking 
>> about our project’s governance and the OFFICIAL policy around backports. I 
>> hope this clarifies what the goal of this thread and discussion is.
>> 
>> There was a prior mentions about this being a branch where backported code 
>> would live and will be untested. Let me clarify that we’re not talking about 
>> just a branch. The project will create artifacts and release them. Having 
>> code living in a repository without being released runs counter to ASF’s 
>> principles.
>> 
>> Thanks,
>> 
>> Dinesh
>> 
>> On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe  
>> wrote:
>>> This sort of has to be about something we’ll do officially as a project, or 
>>> the original post is little more than asking what we think about a public 
>>> fork, which (as bad as it would look for the project) nobody really needs 
>>> approval to do anyway, right?
>>> 
 On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
 
 Thank you for the pointer but I did read it.
 
 My point is that this thread seems to have gone from “let’s create a 
 branch to electively pull changes into” to “we are retrospectively adding 
 a 5.1 branch somewhere between 5.0 and current trunk”, which I think is a 
 completely different discussion.
 
 On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
> I am afraid something like an "enthusiast-driven branch" is not a
> thing. Please read the last email of Jeff, first section.
> 
> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
> >
> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Could you elaborate: I was under impression the new branch is going to 
> > be maintained by a group of enthusiasts. Are we now considering making 
> > this new branch in the upgrade path? This sounds rather different from 
> > the original idea of having an officially supported back port branch.
> >
> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
> >
> > What about this: do a proper 5.1 branch with everything (pipelines, 
> > release ...) but put there only Java 21 support and CEP-37?
> >
> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
> > intact, 5.1 would be a branch we try this new model in, learn the 
> > lessons from it. When we support Java 21 and CEP-37 as only two changes 
> > and nothing else, it will already address Java 21 / unsupported Java 17 
> > concerns and it would bring a lot of relief to people trying to 
> > transition to 6.0 eventually and they would have some time to prepare 
> > for that. Then, in 6.0, TCM / Accord would be production ready waiting 
> > for them to migrate to, while they would already be on Java 21 + 
> > repairs.
> >
> > So for a while we would have
> >
> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
> >
> > 5.0 -> 5.1 -> 6.0 -> trunk
> >
> > Then we can do 6.1 branch and we will have some experience of what 
> > worked / did not and we will be more ready to backport more or we will 
> > just abandon this altogether.
> >
> > My idea is to just do some

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

2025-10-13 Thread Patrick McFadin

And maybe that's where I get confused. I feel like that mechanism exists in
the release versions we support and the cadence we have. If someone wants
to do the work to backport CEP-37 to 5.x, then it will be part of 5.x if
the PMC approves it. No need for a special designation.

On Mon, Oct 13, 2025 at 1:33 PM Jeff Jirsa  wrote:

>
> Jeff has a branch. He proposes back porting a feature he wrote and runs on
> 5.0 to 4.0-something. Jeff does the work. Jeff attests that the branch is
> used a lot and he trusts it. Fine.
>
> What happens to that branch next?
>
> If Patrick also does the same, does it go to the same branch? Or a
> different branch?
>
> If Alex has a security fix, is he obligated to fix Jeff’s branch?
> Patrick’s branch? Every branch?
>
> Making a branch isn’t a big deal. Releasing it is. Maintaining it is.
> What’s the release and maintenance story of the “for the benefit of
> everyone” branch?
>
>
>
>
>
> On Oct 13, 2025, at 1:22 PM, Patrick McFadin  wrote:
>
> What a thread, but a good one.
>
> I'm going to rewind to the very first email Josh sent. At Community over
> Code, I joking(not joking) had a slide that said "Somebody in 2035 will ask
> for a feature to be backported to 3.x" I want to make sure I got what you
> were proposing Josh, because the conversation has been sub-threading.
>
> 1. Create a branch designated explicitly as a backport. You were calling
> it 5.1, but it could easily exist in 4.x
> 2. Somebody wants to backport a feature, instead of doing it on
> $INTERNAL_FORK, propose it on the ML, +1s and then the backport work is for
> the benefit of everyone in the Cassandra community.
>
> Everything else seems like bikeshedding, but I could be wrong. Please
> correct me.
>
> Patrick
>
> On Mon, Oct 13, 2025 at 12:57 PM Dinesh Joshi  wrote:
>
>> The title of this thread is “[DISCUSS] Pilot program of an officially
>> supported backport branch”
>>
>> I want to draw attention to the word _official_. There is nothing
>> unofficial about what is being discussed here. I am not sure why is that
>> word being thrown around in the thread.
>>
>> To the PMCs and Committers on this project in this thread - we are
>> talking about our project’s governance and the OFFICIAL policy around
>> backports. I hope this clarifies what the goal of this thread and
>> discussion is.
>>
>> There was a prior mentions about this being a branch where backported
>> code would live and will be untested. Let me clarify that we’re not talking
>> about just a branch. The project will create artifacts and release them.
>> Having code living in a repository without being released runs counter to
>> ASF’s principles.
>>
>> Thanks,
>>
>> Dinesh
>>
>> On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe <
>> [email protected]> wrote:
>>
>>> This sort of has to be about something we’ll do officially as a project,
>>> or the original post is little more than asking what we think about a
>>> public fork, which (as bad as it would look for the project) nobody really
>>> needs approval to do anyway, right?
>>>
>>> On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
>>>
>>> 
>>>
>>> Thank you for the pointer but I did read it.
>>>
>>> My point is that this thread seems to have gone from “let’s create a
>>> branch to electively pull changes into” to “we are retrospectively adding a
>>> 5.1 branch somewhere between 5.0 and current trunk”, which I think is a
>>> completely different discussion.
>>>
>>> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
>>>
>>> I am afraid something like an "enthusiast-driven branch" is not a
>>> thing. Please read the last email of Jeff, first section.
>>>
>>> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
>>> >
>>> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>>> >
>>> > Could you elaborate: I was under impression the new branch is going to
>>> be maintained by a group of enthusiasts. Are we now considering making this
>>> new branch in the upgrade path? This sounds rather different from the
>>> original idea of having an officially supported back port branch.
>>> >
>>> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
>>> >
>>> > What about this: do a proper 5.1 branch with everything (pipelines,
>>> release ...) but put there only Java 21 support and CEP-37?
>>> >
>>> > Release-wise, the appetite is there (Josh, Bernardo). We would keep
>>> 5.0 intact, 5.1 would be a branch we try this new model in, learn the
>>> lessons from it. When we support Java 21 and CEP-37 as only two changes and
>>> nothing else, it will already address Java 21 / unsupported Java 17
>>> concerns and it would bring a lot of relief to people trying to transition
>>> to 6.0 eventually and they would have some time to prepare for that. Then,
>>> in 6.0, TCM / Accord would be production ready waiting for them to migrate
>>> to, while they would already be on Java 21 + repairs.
>>> >
>>> > So for a while we would have
>>> >
>>> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
>>> >
>>> > Then 6.0 is out, by then,

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

2025-10-13 Thread Jeff Jirsa


Jeff has a branch. He proposes back porting a feature he wrote and runs on 5.0 
to 4.0-something. Jeff does the work. Jeff attests that the branch is used a 
lot and he trusts it. Fine. 

What happens to that branch next?  

If Patrick also does the same, does it go to the same branch? Or a different 
branch?

If Alex has a security fix, is he obligated to fix Jeff’s branch? Patrick’s 
branch? Every branch? 

Making a branch isn’t a big deal. Releasing it is. Maintaining it is. What’s 
the release and maintenance story of the “for the benefit of everyone” branch? 





> On Oct 13, 2025, at 1:22 PM, Patrick McFadin  wrote:
> 
> What a thread, but a good one. 
> 
> I'm going to rewind to the very first email Josh sent. At Community over 
> Code, I joking(not joking) had a slide that said "Somebody in 2035 will ask 
> for a feature to be backported to 3.x" I want to make sure I got what you 
> were proposing Josh, because the conversation has been sub-threading. 
> 
> 1. Create a branch designated explicitly as a backport. You were calling it 
> 5.1, but it could easily exist in 4.x
> 2. Somebody wants to backport a feature, instead of doing it on 
> $INTERNAL_FORK, propose it on the ML, +1s and then the backport work is for 
> the benefit of everyone in the Cassandra community. 
> 
> Everything else seems like bikeshedding, but I could be wrong. Please correct 
> me. 
> 
> Patrick
> 
> On Mon, Oct 13, 2025 at 12:57 PM Dinesh Joshi  > wrote:
>> The title of this thread is “[DISCUSS] Pilot program of an officially 
>> supported backport branch”
>> 
>> I want to draw attention to the word _official_. There is nothing unofficial 
>> about what is being discussed here. I am not sure why is that word being 
>> thrown around in the thread.
>> 
>> To the PMCs and Committers on this project in this thread - we are talking 
>> about our project’s governance and the OFFICIAL policy around backports. I 
>> hope this clarifies what the goal of this thread and discussion is.
>> 
>> There was a prior mentions about this being a branch where backported code 
>> would live and will be untested. Let me clarify that we’re not talking about 
>> just a branch. The project will create artifacts and release them. Having 
>> code living in a repository without being released runs counter to ASF’s 
>> principles.
>> 
>> Thanks,
>> 
>> Dinesh
>> 
>> On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe > > wrote:
>>> This sort of has to be about something we’ll do officially as a project, or 
>>> the original post is little more than asking what we think about a public 
>>> fork, which (as bad as it would look for the project) nobody really needs 
>>> approval to do anyway, right?
>>> 
 On Oct 13, 2025, at 2:28 PM, Alex Petrov >>> > wrote:
 
 
>>> 
 Thank you for the pointer but I did read it.
 
 My point is that this thread seems to have gone from “let’s create a 
 branch to electively pull changes into” to “we are retrospectively adding 
 a 5.1 branch somewhere between 5.0 and current trunk”, which I think is a 
 completely different discussion.
 
 On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
> I am afraid something like an "enthusiast-driven branch" is not a
> thing. Please read the last email of Jeff, first section.
> 
> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  > wrote:
> >
> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Could you elaborate: I was under impression the new branch is going to 
> > be maintained by a group of enthusiasts. Are we now considering making 
> > this new branch in the upgrade path? This sounds rather different from 
> > the original idea of having an officially supported back port branch.
> >
> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
> >
> > What about this: do a proper 5.1 branch with everything (pipelines, 
> > release ...) but put there only Java 21 support and CEP-37?
> >
> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
> > intact, 5.1 would be a branch we try this new model in, learn the 
> > lessons from it. When we support Java 21 and CEP-37 as only two changes 
> > and nothing else, it will already address Java 21 / unsupported Java 17 
> > concerns and it would bring a lot of relief to people trying to 
> > transition to 6.0 eventually and they would have some time to prepare 
> > for that. Then, in 6.0, TCM / Accord would be production ready waiting 
> > for them to migrate to, while they would already be on Java 21 + 
> > repairs.
> >
> > So for a while we would have
> >
> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
> >
> > 5.0 -> 5.1 -> 6.0 -> trunk
> >
> > The

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

I was basing my understanding on the original proposal:

> The proposal we came up with: an official, community‑maintained backport 
> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot for 
> a year and then decide if we want to make it official. The branch would 
> selectively accept non‑disruptive improvements that meet criteria we define 
> together. There’s a lot of OSS prior art here (Lucene, httpd, Hadoop, Kafka, 
> Linux kernel, etc).

emphasis on: “built on current GA release” and “will selectively accept non 
disruptive improvements”. 

It was not clear to me that creating changes in this branch will create work in 
later branches, such as trunk. If my understanding is correct, cutting this 
branch will likely make it a mandatory version in an upgrade path from 4.0 
which I think differs from the initial proposal.

On Mon, Oct 13, 2025, at 9:48 PM, Jeremiah Jordan wrote:
> I have always read this as the back porting of features and releases would be 
> done by some group of interested parties, but the branch itself would be an 
> official branch in the release branch merge path.  Otherwise I don’t see is 
> much point.
> 
> -Jeremiah
> 
> On Mon, Oct 13, 2025 at 2:40 PM Caleb Rackliffe  
> wrote:
>> This sort of has to be about something we’ll do officially as a project, or 
>> the original post is little more than asking what we think about a public 
>> fork, which (as bad as it would look for the project) nobody really needs 
>> approval to do anyway, right?
>> 
>>> On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
>>> 
>>> Thank you for the pointer but I did read it.
>>> 
>>> My point is that this thread seems to have gone from “let’s create a branch 
>>> to electively pull changes into” to “we are retrospectively adding a 5.1 
>>> branch somewhere between 5.0 and current trunk”, which I think is a 
>>> completely different discussion.
>>> 
>>> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
 I am afraid something like an "enthusiast-driven branch" is not a
 thing. Please read the last email of Jeff, first section.
 
 On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
 >
 > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
 >
 > Could you elaborate: I was under impression the new branch is going to 
 > be maintained by a group of enthusiasts. Are we now considering making 
 > this new branch in the upgrade path? This sounds rather different from 
 > the original idea of having an officially supported back port branch.
 >
 > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
 >
 > What about this: do a proper 5.1 branch with everything (pipelines, 
 > release ...) but put there only Java 21 support and CEP-37?
 >
 > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
 > intact, 5.1 would be a branch we try this new model in, learn the 
 > lessons from it. When we support Java 21 and CEP-37 as only two changes 
 > and nothing else, it will already address Java 21 / unsupported Java 17 
 > concerns and it would bring a lot of relief to people trying to 
 > transition to 6.0 eventually and they would have some time to prepare 
 > for that. Then, in 6.0, TCM / Accord would be production ready waiting 
 > for them to migrate to, while they would already be on Java 21 + repairs.
 >
 > So for a while we would have
 >
 > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
 >
 > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
 >
 > 5.0 -> 5.1 -> 6.0 -> trunk
 >
 > Then we can do 6.1 branch and we will have some experience of what 
 > worked / did not and we will be more ready to backport more or we will 
 > just abandon this altogether.
 >
 > My idea is to just do something quick yet already beneficial. If we 
 > backport only Java 21 and CEP-37 then upgrade paths will be pretty 
 > smooth, nothing new will be there to cause any friction.
 >
 > As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 
 > -> 5.1 would be very easy, in majority of cases just clean merges up.
 >
 > The only overhead is CI but we have pre-ci too which we can leverage so 
 > ...
 >
 > I would be more open to this if we agreed that the scope of the 
 > backporting on this initial pilot will be limited to a minimum of 
 > features and nothing else. Then we can just reflect on what we did.
 >
 > On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
 >
 >
 >
 > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  
 > > wrote:
 > >
 > > To respond to some of the other points and throw my perspective into 
 > > the mix:
 > >
 > >> Release engineering for a branch is nearly a full-time job.
 > > While release management is a burden (and one we've had a hard time 
 > > resourcing for years), I don't see it as being near

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

2025-10-13 Thread Dinesh Joshi

The title of this thread is “[DISCUSS] Pilot program of an officially
supported backport branch”

I want to draw attention to the word _official_. There is nothing
unofficial about what is being discussed here. I am not sure why is that
word being thrown around in the thread.

To the PMCs and Committers on this project in this thread - we are talking
about our project’s governance and the OFFICIAL policy around backports. I
hope this clarifies what the goal of this thread and discussion is.

There was a prior mentions about this being a branch where backported code
would live and will be untested. Let me clarify that we’re not talking
about just a branch. The project will create artifacts and release them.
Having code living in a repository without being released runs counter to
ASF’s principles.

Thanks,

Dinesh

On Mon, Oct 13, 2025 at 12:41 PM Caleb Rackliffe 
wrote:

> This sort of has to be about something we’ll do officially as a project,
> or the original post is little more than asking what we think about a
> public fork, which (as bad as it would look for the project) nobody really
> needs approval to do anyway, right?
>
> On Oct 13, 2025, at 2:28 PM, Alex Petrov  wrote:
>
> 
>
> Thank you for the pointer but I did read it.
>
> My point is that this thread seems to have gone from “let’s create a
> branch to electively pull changes into” to “we are retrospectively adding a
> 5.1 branch somewhere between 5.0 and current trunk”, which I think is a
> completely different discussion.
>
> On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
>
> I am afraid something like an "enthusiast-driven branch" is not a
> thing. Please read the last email of Jeff, first section.
>
> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
> >
> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Could you elaborate: I was under impression the new branch is going to
> be maintained by a group of enthusiasts. Are we now considering making this
> new branch in the upgrade path? This sounds rather different from the
> original idea of having an officially supported back port branch.
> >
> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
> >
> > What about this: do a proper 5.1 branch with everything (pipelines,
> release ...) but put there only Java 21 support and CEP-37?
> >
> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0
> intact, 5.1 would be a branch we try this new model in, learn the lessons
> from it. When we support Java 21 and CEP-37 as only two changes and nothing
> else, it will already address Java 21 / unsupported Java 17 concerns and it
> would bring a lot of relief to people trying to transition to 6.0
> eventually and they would have some time to prepare for that. Then, in 6.0,
> TCM / Accord would be production ready waiting for them to migrate to,
> while they would already be on Java 21 + repairs.
> >
> > So for a while we would have
> >
> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
> >
> > 5.0 -> 5.1 -> 6.0 -> trunk
> >
> > Then we can do 6.1 branch and we will have some experience of what
> worked / did not and we will be more ready to backport more or we will just
> abandon this altogether.
> >
> > My idea is to just do something quick yet already beneficial. If we
> backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth,
> nothing new will be there to cause any friction.
> >
> > As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0
> -> 5.1 would be very easy, in majority of cases just clean merges up.
> >
> > The only overhead is CI but we have pre-ci too which we can leverage so
> ...
> >
> > I would be more open to this if we agreed that the scope of the
> backporting on this initial pilot will be limited to a minimum of features
> and nothing else. Then we can just reflect on what we did.
> >
> > On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
> >
> >
> >
> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie 
> wrote:
> > >
> > > To respond to some of the other points and throw my perspective into
> the mix:
> > >
> > >> Release engineering for a branch is nearly a full-time job.
> > > While release management is a burden (and one we've had a hard time
> resourcing for years), I don't see it as being nearly a full-time job per
> branch. We also have contributors willing to step forward and take on this
> extra work and plenty of opportunity for automation on both release
> preparation and validation that would lower that burden further.
> > >
> > >> Unofficial branches will miss correctness and compatibility fixes
> unless their maintenance is made a burden for all committers.
> > > Both proposals (backport to 5.0, support a 5.1 that accepts backport)
> would be considered official during the pilot. Bugfixes that are 5.0 or
> older would have 1 more branch they needed to apply to and merge through.
> > >
> >
> > I see the word unofficial used too many t

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

Thank you for the pointer but I did read it.

My point is that this thread seems to have gone from “let’s create a branch to 
electively pull changes into” to “we are retrospectively adding a 5.1 branch 
somewhere between 5.0 and current trunk”, which I think is a completely 
different discussion.

On Mon, Oct 13, 2025, at 9:15 PM, Štefan Miklošovič wrote:
> I am afraid something like an "enthusiast-driven branch" is not a
> thing. Please read the last email of Jeff, first section.
> 
> On Mon, Oct 13, 2025 at 9:12 PM Alex Petrov  wrote:
> >
> > > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Could you elaborate: I was under impression the new branch is going to be 
> > maintained by a group of enthusiasts. Are we now considering making this 
> > new branch in the upgrade path? This sounds rather different from the 
> > original idea of having an officially supported back port branch.
> >
> > On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
> >
> > What about this: do a proper 5.1 branch with everything (pipelines, release 
> > ...) but put there only Java 21 support and CEP-37?
> >
> > Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
> > intact, 5.1 would be a branch we try this new model in, learn the lessons 
> > from it. When we support Java 21 and CEP-37 as only two changes and nothing 
> > else, it will already address Java 21 / unsupported Java 17 concerns and it 
> > would bring a lot of relief to people trying to transition to 6.0 
> > eventually and they would have some time to prepare for that. Then, in 6.0, 
> > TCM / Accord would be production ready waiting for them to migrate to, 
> > while they would already be on Java 21 + repairs.
> >
> > So for a while we would have
> >
> > 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> >
> > Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be
> >
> > 5.0 -> 5.1 -> 6.0 -> trunk
> >
> > Then we can do 6.1 branch and we will have some experience of what worked / 
> > did not and we will be more ready to backport more or we will just abandon 
> > this altogether.
> >
> > My idea is to just do something quick yet already beneficial. If we 
> > backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth, 
> > nothing new will be there to cause any friction.
> >
> > As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 -> 
> > 5.1 would be very easy, in majority of cases just clean merges up.
> >
> > The only overhead is CI but we have pre-ci too which we can leverage so ...
> >
> > I would be more open to this if we agreed that the scope of the backporting 
> > on this initial pilot will be limited to a minimum of features and nothing 
> > else. Then we can just reflect on what we did.
> >
> > On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
> >
> >
> >
> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  wrote:
> > >
> > > To respond to some of the other points and throw my perspective into the 
> > > mix:
> > >
> > >> Release engineering for a branch is nearly a full-time job.
> > > While release management is a burden (and one we've had a hard time 
> > > resourcing for years), I don't see it as being nearly a full-time job per 
> > > branch. We also have contributors willing to step forward and take on 
> > > this extra work and plenty of opportunity for automation on both release 
> > > preparation and validation that would lower that burden further.
> > >
> > >> Unofficial branches will miss correctness and compatibility fixes unless 
> > >> their maintenance is made a burden for all committers.
> > > Both proposals (backport to 5.0, support a 5.1 that accepts backport) 
> > > would be considered official during the pilot. Bugfixes that are 5.0 or 
> > > older would have 1 more branch they needed to apply to and merge through.
> > >
> >
> > I see the word unofficial used too many times. There’s no such thing as 
> > unofficial. If it’s merged by committers and voted on for release by the 
> > PMC, it’s official. If it’s not, it doesn’t belong in the ASF repos.
> >
> > >
> > >> – Backports branches don’t solve the “some people run forks” problem.
> > > I see this a bit differently; it doesn't "solve" the problem (I don't 
> > > personally see this as a problem to be solved fwiw), but it does bring 
> > > those forks much closer to upstream and move engineering effort that 
> > > would otherwise be on private forks into the public space benefiting 
> > > everyone.
> >
> > I think you’ve seen at least a few reasons in this thread why the goal and 
> > proposal may not align. What one team considers ready and low risk, another 
> > team begs not to be included. I suspect if there was really, truly a shared 
> > understanding of “this is back port ready, low risk, ready to run”, we 
> > could just put it into the existing branches (with a “yes this is a 
> > feature, but it’s a feature we all trust” discussion)?
> >
> >
>

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

2025-10-13 Thread Štefan Miklošovič

That is a good question. I do not mind having it either way. I was
just writing that in the spirit of Jeff's email where
enthusiast-driven and unofficial is not something to do. If we agree
on that being relaxed I ultimately don't mind.

On Mon, Oct 13, 2025 at 9:18 PM Alex Petrov  wrote:
>
> > Any protocol changes in the backport branch would need to be validated from 
> > 5.0 and to 6.0, but otherwise not increase the surface area of breakage.
>
> This sounds like backport branches are going to create substantial burden for 
> active maintainers.
>
> For most of the discussion it sounded more like a backport branch will be 
> created and maintained by a select group of volunteers who want to help the 
> community by making a small number of patches also available in other 
> branches. This means it will not be on an active merge path (i.e., when 
> merging something into 5.0, you skip the backport branches and go straight to 
> 6.0), and all changes will be pulled there electively. Also, active 
> maintainers will not have to reason through which backport branches there 
> exist and which compatibility implications they impose.
>
> Has this changed over the course of the discussion?
>
> On Mon, Oct 13, 2025, at 4:02 PM, Josh McKenzie wrote:
>
> To respond to some of the other points and throw my perspective into the mix:
>
> Release engineering for a branch is nearly a full-time job.
>
> While release management is a burden (and one we've had a hard time 
> resourcing for years), I don't see it as being nearly a full-time job per 
> branch. We also have contributors willing to step forward and take on this 
> extra work and plenty of opportunity for automation on both release 
> preparation and validation that would lower that burden further.
>
> Unofficial branches will miss correctness and compatibility fixes unless 
> their maintenance is made a burden for all committers.
>
> Both proposals (backport to 5.0, support a 5.1 that accepts backport) would 
> be considered official during the pilot. Bugfixes that are 5.0 or older would 
> have 1 more branch they needed to apply to and merge through.
>
> – The upgrade matrix becomes more complicated. As features are backported... 
> these upgrade paths will be untested and unexercised.
>
> I agree the matrix would become more complicated but disagree that they would 
> be untested and unexercised. I also think the marginal increase in complexity 
> is worth taking on for the expected benefits.
>
> For example, with the "cassandra-5.1-backport" branch, we could support:
>
> 4.1-5.0
> 5.0-6.0
> (new) 5.0-5.1-6.0
>
>
> This would add 2 new paths to test and add one backport-branch-specific 
> constraint (must go through 5.0 to get to 5.1). Any protocol changes in the 
> backport branch would need to be validated from 5.0 and to 6.0, but otherwise 
> not increase the surface area of breakage.
>
> Those types of changes would already need to be verified in the current 
> status quo in the 5.0-6.0 path; introducing a branch in the middle that 
> received a backport would involve validating that same functional change from 
> 5.0-5.1 as from 5.0-6.0 prior, just in whatever differing context might be on 
> that branch.
>
> – There’s an assumption in this thread that backports are easy to pick up.
>
> I see this discussion as an exploration on how skilled contributors and 
> committers can deduplicate their work on private forks, bring those forks 
> closer to upstream, and make certain new features available to end users 
> earlier. I haven't read anything as implying backporting is easy.
>
> – Backports branches don’t solve the “some people run forks” problem.
>
> I see this a bit differently; it doesn't "solve" the problem (I don't 
> personally see this as a problem to be solved fwiw), but it does bring those 
> forks much closer to upstream and move engineering effort that would 
> otherwise be on private forks into the public space benefiting everyone.
>
> – Backports branches don’t solve the user community adoption problem either, 
> unless we’re also publishing per-OS packages, Maven artifacts, etc.
>
> I agree with you that we have a "time to new release" adoption problem 
> broadly but I don't see this thread as attempting to address that; do we 
> think providing a middle-ground release between frozen GA and feature-dense 
> higher risk trunk would worsen adoption?
>
> ---
>
> I think a follow-up discussion about how we can enable and encourage users to 
> test trunk or run releases cut from it (alphas cut monthly or quarterly) 
> would be a great use of our time and energy.
>
> I also think it would be valuable to have a follow up discussion about how we 
> can change our engineering practices to make GA releases less disruptive for 
> users to transition onto, allow users to incrementally validate new optional 
> features, and roll back to older releases with confidence in the event of 
> defects (see prior email).
>
>
> On Sun, Oct 12, 2025, at 12:03 PM

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

> 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk

Could you elaborate: I was under impression the new branch is going to be 
maintained by a group of enthusiasts. Are we now considering making this new 
branch in the upgrade path? This sounds rather different from the original idea 
of having an officially supported back port branch.

On Mon, Oct 13, 2025, at 8:13 PM, Štefan Miklošovič wrote:
> What about this: do a proper 5.1 branch with everything (pipelines, release 
> ...) but put there only Java 21 support and CEP-37?
> 
> Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0 
> intact, 5.1 would be a branch we try this new model in, learn the lessons 
> from it. When we support Java 21 and CEP-37 as only two changes and nothing 
> else, it will already address Java 21 / unsupported Java 17 concerns and it 
> would bring a lot of relief to people trying to transition to 6.0 eventually 
> and they would have some time to prepare for that. Then, in 6.0, TCM / Accord 
> would be production ready waiting for them to migrate to, while they would 
> already be on Java 21 + repairs.
> 
> So for a while we would have 
> 
> 4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk
> 
> Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be 
> 
> 5.0 -> 5.1 -> 6.0 -> trunk
> 
> Then we can do 6.1 branch and we will have some experience of what worked / 
> did not and we will be more ready to backport more or we will just abandon 
> this altogether.
> 
> My idea is to just do something quick yet already beneficial. If we backport 
> only Java 21 and CEP-37 then upgrade paths will be pretty smooth, nothing new 
> will be there to cause any friction.
> 
> As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 -> 5.1 
> would be very easy, in majority of cases just clean merges up.
> 
> The only overhead is CI but we have pre-ci too which we can leverage so ...
> 
> I would be more open to this if we agreed that the scope of the backporting 
> on this initial pilot will be limited to a minimum of features and nothing 
> else. Then we can just reflect on what we did.
> 
> On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:
>> 
>> 
>> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  wrote:
>> > 
>> > To respond to some of the other points and throw my perspective into the 
>> > mix:
>> > 
>> >> Release engineering for a branch is nearly a full-time job.
>> > While release management is a burden (and one we've had a hard time 
>> > resourcing for years), I don't see it as being nearly a full-time job per 
>> > branch. We also have contributors willing to step forward and take on this 
>> > extra work and plenty of opportunity for automation on both release 
>> > preparation and validation that would lower that burden further.
>> > 
>> >> Unofficial branches will miss correctness and compatibility fixes unless 
>> >> their maintenance is made a burden for all committers.
>> > Both proposals (backport to 5.0, support a 5.1 that accepts backport) 
>> > would be considered official during the pilot. Bugfixes that are 5.0 or 
>> > older would have 1 more branch they needed to apply to and merge through.
>> > 
>> 
>> I see the word unofficial used too many times. There’s no such thing as 
>> unofficial. If it’s merged by committers and voted on for release by the 
>> PMC, it’s official. If it’s not, it doesn’t belong in the ASF repos. 
>> 
>> > 
>> >> – Backports branches don’t solve the “some people run forks” problem.
>> > I see this a bit differently; it doesn't "solve" the problem (I don't 
>> > personally see this as a problem to be solved fwiw), but it does bring 
>> > those forks much closer to upstream and move engineering effort that would 
>> > otherwise be on private forks into the public space benefiting everyone.
>> 
>> I think you’ve seen at least a few reasons in this thread why the goal and 
>> proposal may not align. What one team considers ready and low risk, another 
>> team begs not to be included. I suspect if there was really, truly a shared 
>> understanding of “this is back port ready, low risk, ready to run”, we could 
>> just put it into the existing branches (with a “yes this is a feature, but 
>> it’s a feature we all trust” discussion)?
>>

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

2025-10-13 Thread Štefan Miklošovič

What about this: do a proper 5.1 branch with everything (pipelines, release
...) but put there only Java 21 support and CEP-37?

Release-wise, the appetite is there (Josh, Bernardo). We would keep 5.0
intact, 5.1 would be a branch we try this new model in, learn the lessons
from it. When we support Java 21 and CEP-37 as only two changes and nothing
else, it will already address Java 21 / unsupported Java 17 concerns and it
would bring a lot of relief to people trying to transition to 6.0
eventually and they would have some time to prepare for that. Then, in 6.0,
TCM / Accord would be production ready waiting for them to migrate to,
while they would already be on Java 21 + repairs.

So for a while we would have

4.0 -> 4.1 -> 5.0 -> 5.1 -> trunk

Then 6.0 is out, by then, we will deprecate 4.x, right? So it would be

5.0 -> 5.1 -> 6.0 -> trunk

Then we can do 6.1 branch and we will have some experience of what worked /
did not and we will be more ready to backport more or we will just abandon
this altogether.

My idea is to just do something quick yet already beneficial. If we
backport only Java 21 and CEP-37 then upgrade paths will be pretty smooth,
nothing new will be there to cause any friction.

As 5.0 / 5.1 will diverge relatively very little, all patches from 5.0 ->
5.1 would be very easy, in majority of cases just clean merges up.

The only overhead is CI but we have pre-ci too which we can leverage so ...

I would be more open to this if we agreed that the scope of the backporting
on this initial pilot will be limited to a minimum of features and nothing
else. Then we can just reflect on what we did.

On Mon, Oct 13, 2025 at 7:38 PM Jeff Jirsa  wrote:

>
>
> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie  wrote:
> >
> > To respond to some of the other points and throw my perspective into the
> mix:
> >
> >> Release engineering for a branch is nearly a full-time job.
> > While release management is a burden (and one we've had a hard time
> resourcing for years), I don't see it as being nearly a full-time job per
> branch. We also have contributors willing to step forward and take on this
> extra work and plenty of opportunity for automation on both release
> preparation and validation that would lower that burden further.
> >
> >> Unofficial branches will miss correctness and compatibility fixes
> unless their maintenance is made a burden for all committers.
> > Both proposals (backport to 5.0, support a 5.1 that accepts backport)
> would be considered official during the pilot. Bugfixes that are 5.0 or
> older would have 1 more branch they needed to apply to and merge through.
> >
>
> I see the word unofficial used too many times. There’s no such thing as
> unofficial. If it’s merged by committers and voted on for release by the
> PMC, it’s official. If it’s not, it doesn’t belong in the ASF repos.
>
> >
> >> – Backports branches don’t solve the “some people run forks” problem.
> > I see this a bit differently; it doesn't "solve" the problem (I don't
> personally see this as a problem to be solved fwiw), but it does bring
> those forks much closer to upstream and move engineering effort that would
> otherwise be on private forks into the public space benefiting everyone.
>
> I think you’ve seen at least a few reasons in this thread why the goal and
> proposal may not align. What one team considers ready and low risk, another
> team begs not to be included. I suspect if there was really, truly a shared
> understanding of “this is back port ready, low risk, ready to run”, we
> could just put it into the existing branches (with a “yes this is a
> feature, but it’s a feature we all trust” discussion)?
>
>
>

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

2025-10-13 Thread Josh McKenzie

> Convenience features like CEP-37. This isn't solving an issue that existing 
> operators haven't already had to solve with some external tool such as Reaper.
I wish this were true. Every time Patrick's surveyed the community and in every 
other dataset I've seen the number of operators who don't run repair is 
horrifying. CEP-37 is kind of unique in that respect; I can't think of any 
other major fundamental gaps in functionality we've just foisted on our users 
like repair.

So zooming out to confirm we're aligned on the big picture:
 1. What is the problem we're trying to solve?
 2. Why does that problem exist? This will inform:
 3. How do we want to solve that problem?

My understanding right now:
 1. There's a lot of duplicate effort going into maintaining private backport 
forks of the database. This effort could instead go to public collaboration 
lowering the burden on everyone and increasing value to our users and ecosystem 
and people would prefer that.
 2. Because **the perception of** upgrading major versions of C* remains 
difficult and dangerous (we should explore this more). I say "perception of" 
because there seems to be differing views here of where we are right now.
 3. This thread is suggesting we solve that problem via making a backport 
branch/release public and a 1st class citizen

A backport branch is really a workaround to separate perceived lower risk 
features from higher risk.

Another approach would be to discuss and agree upon a set of criteria we will 
apply to all new features before merging to lower the risk of adoption. This 
would not resolve any currently merged features that don't yet meet that bar; 
contributors would need to step up and bring all currently merged features into 
compliance to bring trunk into a state where operators and non-authors would be 
comfortable running a release cut from it.

On Mon, Oct 13, 2025, at 8:52 AM, Michael Burman wrote:
> I feel like this thread only highlights the problems with the current release 
> model and how long it takes to get the next version out. Maybe that's because 
> of feature creep or development model itself (too many changes in a single 
> version), but clearly there's so many contradicting wishes in the thread that 
> in my opinion the entire idea of -backports branch starts to make no sense. 
> I'm probably just repeating what others have said, but here's one more 
> opinion.
> 
> So far I've seen three different categories.
> 
> 1. Runtime impact, such as JDK 21 support. Since JDK17 is soon EOL for some 
> support companies, personally this is already starting to feel like a bug 
> that it's not supported in the 5.0 branch. This directly impacts the user's 
> ability to run on supported platforms. Sure, some providers do support until 
> Sep/Oct 2027, but that's not far away if people wish to migrate from older 
> versions of Cassandra as they might have to instantly start running an 
> unsupported base OS or buy support from external vendor. Personally, this has 
> been the only thing here that I see as "this really is relevant backport to 
> stable branch" in this discussion.
> 2. Major features like TCM/Accord. Isn't these types of "breaking" changes 
> exactly why we change major version number? It's also something that we want 
> to advertise as major features not available in earlier versions. If we port 
> back everything fancy from 6.0 to 5.1, then why release 6.0 at all? Just call 
> it 5.1 then.
> 3. Convenience features like CEP-37. This isn't solving an issue that 
> existing operators haven't already had to solve with some external tool such 
> as Reaper. I don't see how this would make migrations easier as they already 
> have a solution in place for 4.1 which works as is for their 5.0 cluster 
> also. The next major version solving this is again a nice thing to advertise 
> as a bonus and should make people more eager to update. Starting backport of 
> these convenience features opens a floodgate, everyone then wants something 
> nice like the split of YAML files and suddenly something "innocent" starts 
> breaking entire clusters because a certain edge case that used to work 
> doesn't suddenly work. "No one uses this.." This has happened in the past. 
> 
> Faster release cadence would probably be my favourite choice, but it has its 
> own issues with support policy also and probably should be done in a separate 
> discussion. As Josh said in the first message, there's clearly a lot of 
> examples (I would have said FreeBSD since it has a very long history of doing 
> this, but it is a slightly different model also) but I also think it's a bit 
> late for these at this stage and would make more sense to do after releasing 
> 6.0 and before beginning a new cycle. At that point it would be easier to 
> modify the process to include 7.0+6.1 for example as then it would be clear 
> to the end users also what kind of releases to expect. Now there's been so 
> many changes to the trunk already that th

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

2025-10-13 Thread Michael Burman

I feel like this thread only highlights the problems with the current
release model and how long it takes to get the next version out. Maybe
that's because of feature creep or development model itself (too many
changes in a single version), but clearly there's so many contradicting
wishes in the thread that in my opinion the entire idea of -backports
branch starts to make no sense. I'm probably just repeating what others
have said, but here's one more opinion.

So far I've seen three different categories.

1. Runtime impact, such as JDK 21 support. Since JDK17 is soon EOL for some
support companies, personally this is already starting to feel like a bug
that it's not supported in the 5.0 branch. This directly impacts the user's
ability to run on supported platforms. Sure, some providers do support
until Sep/Oct 2027, but that's not far away if people wish to migrate from
older versions of Cassandra as they might have to instantly start running
an unsupported base OS or buy support from external vendor. Personally,
this has been the only thing here that I see as "this really is relevant
backport to stable branch" in this discussion.
2. Major features like TCM/Accord. Isn't these types of "breaking" changes
exactly why we change major version number? It's also something that we
want to advertise as major features not available in earlier versions. If
we port back everything fancy from 6.0 to 5.1, then why release 6.0 at all?
Just call it 5.1 then.
3. Convenience features like CEP-37. This isn't solving an issue that
existing operators haven't already had to solve with some external tool
such as Reaper. I don't see how this would make migrations easier as they
already have a solution in place for 4.1 which works as is for their 5.0
cluster also. The next major version solving this is again a nice thing to
advertise as a bonus and should make people more eager to update. Starting
backport of these convenience features opens a floodgate, everyone then
wants something nice like the split of YAML files and suddenly something
"innocent" starts breaking entire clusters because a certain edge case that
used to work doesn't suddenly work. "No one uses this.." This has happened
in the past.

Faster release cadence would probably be my favourite choice, but it has
its own issues with support policy also and probably should be done in a
separate discussion. As Josh said in the first message, there's clearly a
lot of examples (I would have said FreeBSD since it has a very long history
of doing this, but it is a slightly different model also) but I also think
it's a bit late for these at this stage and would make more sense to do
after releasing 6.0 and before beginning a new cycle. At that point it
would be easier to modify the process to include 7.0+6.1 for example as
then it would be clear to the end users also what kind of releases to
expect. Now there's been so many changes to the trunk already that this is
going to require a lot of work and 5.0 has been out for over a year.

  - Micke

On Mon, 13 Oct 2025 at 14:02, Štefan Miklošovič 
wrote:

> I agree with all of that, Alex.
>
> Plus, I am not completely sure how that would look like in practice,
> e.g. porting TCM to 5.0, (maybe somebody already has a fork like that
> so they can elaborate more), but my guess is that thing like that
> would be quite tricky to backport. All I am saying is that it might be
> more work than anticipated, then we would be porting for next half a
> year with all "ah we need to tweak this here as well to have backport
> right" and it might actually produce way more work than if somebody
> just upgraded and be done with it.
>
> On Mon, Oct 13, 2025 at 11:04 AM Alex Petrov  wrote:
> >
> > > For instance, when upgrading to 5.1, a lack of a straightforward
> rollback path can make the process risky.
> >
> > @Jaydeep Chovatia, could you elaborate on this, since to my best
> knowledge there _is_ a straightforward rollback path for the features I am
> aware of. You can enable Accord transactions and later disable them, and
> you can also migrate back to Gossip from TCM. Both of these
> upgrade/downgrade paths are thoroughly tested. If there are other features
> that lack downgrade path, please mention them.
> >
> > On Sun, Oct 12, 2025, at 9:12 PM, Jaydeep Chovatia wrote:
> >
> > Here is my opinion.
> >
> > >– Unofficial branches will miss correctness and compatibility fixes
> unless their maintenance is made a burden for all committers. If not,
> they’ll be buggier and more prone to data loss than trunk.
> >
> > Typically, the backporting effort is handled by the author or co-author
> of a given CEP. As long as they are motivated to pursue the backport, I
> don’t anticipate this being a concern. In most cases, their motivation
> naturally comes from the fact that they are themselves relying on or
> benefiting from the backported version.
> >
> > >– The upgrade matrix becomes more complicated. As features are
> backported, any change affecting i

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