[DISCUSS] Pilot program of an officially supported backport branch

[Josh McKenzie <jm...@apache.org>]

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

[Josh McKenzie <jm...@apache.org>]

> 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 <co...@bernardobotella.com> 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 <pa...@gmail.com> 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 <ch...@gmail.com> 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 <is...@gmail.com> 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) <ra...@anant.us> 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

[Josh McKenzie <jm...@apache.org>]

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 <co...@bernardobotella.com> 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 <pa...@gmail.com> 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 <ch...@gmail.com> 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 <is...@gmail.com> 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) <ra...@anant.us> 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

[Jeremiah Jordan <je...@apache.org>]

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 <
contacto@bernardobotella.com> 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 <pa...@gmail.com>
> 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 <
> chovatia.jaydeep@gmail.com> 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 <is...@gmail.com> 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) <ra...@anant.us>
>>> 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

[Bernardo Botella <co...@bernardobotella.com>]

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 <pa...@gmail.com> 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 <chovatia.jaydeep@gmail.com <ma...@gmail.com>> 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 <isaacreath@gmail.com <ma...@gmail.com>> 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) <rahul.singh@anant.us <ma...@anant.us>> 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

[Patrick Lee <pa...@gmail.com>]

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 <ch...@gmail.com>
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 <is...@gmail.com> 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) <ra...@anant.us>
>> 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

[Jaydeep Chovatia <ch...@gmail.com>]

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 <is...@gmail.com> 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) <ra...@anant.us>
> 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

[Isaac Reath <is...@gmail.com>]

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) <ra...@anant.us>
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

["Rahul Singh (ANANT)" <ra...@anant.us>]

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

[Alex Petrov <al...@coffeenco.de>]

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

[Caleb Rackliffe <ca...@gmail.com>]

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 <je...@gmail.com> 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 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 <e....@gmail.com>
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
<[jjirsa@gmail.com](mailto:jjirsa@gmail.com)> 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
> <[jmckenzie@apache.org](mailto:jmckenzie@apache.org)> 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

[Jeremy Hanna <je...@gmail.com>]

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 <e....@gmail.com> 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 <jjirsa@gmail.com <ma...@gmail.com>> 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 <jmckenzie@apache.org <ma...@apache.org>> 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

[Ekaterina Dimitrova <e....@gmail.com>]

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 <jj...@gmail.com> 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 <jm...@apache.org> 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

[Isaac Reath <is...@gmail.com>]

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 <fr...@apache.org>
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

[Francisco Guerrero <fr...@apache.org>]

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

[Josh McKenzie <jm...@apache.org>]

> 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

[Mick <mc...@apache.org>]

> 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

[Dinesh Joshi <dj...@apache.org>]

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 <jm...@apache.org> 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 <jm...@apache.org>
> escribió:
>
> 
> I'll take a crack at those questions Dinesh:
>
> 1. What branch would be designated as a backports branch?
>
> A new branch ( cassandra-5.1 ) should be created. While reusing
> cassandra-5.0 reduces overhead, changing the identity of a GA release
> mid-lifecycle risks breaking user trust (Isaac's point holds as
> foundational to me). We have no way of knowing how many operators rely on
> 5.0’s stability contract.
>
> 2. What are the tradeoffs of reusing an existing vs new branch?
>
> *Reusing 5.0 (existing):*
> *- Pros:* Lower maintenance burden (fewer merges, fewer releases, less
> CI).
> *- Cons:* Violates the stability contract we put out for a GA release;
> erodes trust; risks destabilizing a widely deployed branch.
>
> *New branch (5.1):*
> *- Pros:* Preserves 5.0 as a true GA; creates clear separation between
> stable and community-backported features; aligns with OSS best practice /
> prior art
> - *Cons:* Adds maintenance overhead (merges, CI, releases); lifecycle
> ambiguity (when does it EOL?); higher initial setup cost.
>
> 3. What would releases look like including release cadence?
>
> "5.1.0-beta", "5.1.0-backport", "5.1.0-community"; some flag to denote
> "not regular GA".
> Cadence: No fixed schedule (same as current GA). Reactive to feature
> merge or volume of smaller improvements, critical bugfixes, etc.
>
> 4. What would be the success criteria of this pilot?
>
> - Increased community engagement (features backported in, releases cut);
> draw down of private forks
> - More contributors stepping up as release managers to maintain this branch
> - Multiple non-trivial production deployments using backport branch
> - Acceptable stability and trust in the backport branch releases
>
> 5. What is the proposed time duration of the pilot?
>
> 12 months, with quarterly [DISCUSS] retro check-ins on dev@.
>
> If successful, we should consider evolving the model to: the latest GA
> release may accept community-approved backports. Only after proving the
> process works outside the GA branch first and only if we can signal this
> at the initial cut of the release.
>
>
> On Thu, Oct 9, 2025, at 5:05 PM, Dinesh Joshi wrote:
>
> Wanted to recenter this conversation on the proposal and summarize my
> understanding –
>
> 1. Our community wants a backports release and a stable release of
> cassandra.
> 2. Some operators would prefer to backports while others are ok waiting
> until the next major.
> 3. We are not talking about backporting all features only limited set of
> features in consultation with the broader community.
> 4. This is a limited time pilot.
>
> Advantages:
> 1. We satisfy broader community needs.
> 2. By keeping backports and stable releases separate, we isolate risks to
> backports branch & release.
> 3. Limited time experiment allows us to adjust this approach including
> sunsetting it if we determine that we don't serve the community's need or
> excessive burden on maintainers.
> 4. Allows broader participation and growing the community.
>
> Concerns:
> 1. Maintenance burden on existing maintainers - more releases, more
> artifacts, more targets to patch & merge.
> 2. Lack of sufficient release managers, maintainers, etc.
>
> Mitigations:
>
> Maintenance burden & lack of sufficient release managers – this is a
> broader pre-existing issue which will be exacerbated unless we get more
> people signed up for releases and maintaining. My expectation is that
> contributors who are enthusiastic about championing this proposal should
> commit to taking on that burden. I also expect that PMC members and
> Committers will sign up to support the contributors to make this
> successful. We will evaluate the success at the end of the pilot period and
> figure out the a way forward.
>
> On Aleksey's point about just broadening the backporting criteria, I
> honestly have mixed feelings about this approach. In the past there has
> been a fear of destabilizing a released, stable branch so we limited the
> patches to security fixes and critical bug fixes. I am sure those concerns
> do still exist. Once we run this pilot, we will have a better understanding
> of the adoption rate of backports release vs stable release. If the data
> suggests that most people are comfortable taking backports release, we can
> revisit the project's governance and broaden the criteria. I would really
> like to defer making this decision until then.
>
> If everybody is generally onboard with the proposal, we can start getting
> into the details of the logistics and I would suggest we circle back with
> more details which include -
>
> 1. What branch would be designated as a backports branch?
> 2. What are the tradeoffs of reusing an existing vs new branch?
> 3. What would releases look like including release cadence?
> 4. What would be the success criteria of this pilot?
> 5. What is the proposed time duration of the pilot?
>
> Thanks,
>
> Dinesh
>
>
> On Thu, Oct 9, 2025 at 9:29 AM Patrick Lee <pa...@gmail.com>
> wrote:
>
> I wanted to share some thoughts from a user perspective on how we get
> features released sooner.
>
> When 5.0 was released, there were statements like *“5.1 will be released
> very soon with even more features.”* At conferences and presentations, we
> showcase all these new capabilities, which drives a lot of excitement—but
> it often takes a while before those features are available in a release.
>
> I really appreciate the stability of our releases and wouldn’t want to
> compromise that. Upgrading fleets takes time, and we don’t always jump on
> every new version immediately. That said, when I see features that help me,
> I adopt them quickly—at least for new deployments—to evaluate stability in
> our environment as we expand and upgrade.
>
> Right now, I’m working on handling repairs differently than before. With
> CEP-37 in truck, I’m questioning how long I should wait. Why spend time
> implementing something else if Cassandra will soon support this? If I have
> to wait until 6.0, I have no idea how long that will take. My options
> become:
>
>    1. Wait for the official release.
>    2. Build a temporary solution, knowing it’s short-lived.
>    3. Maintain an internal fork and backport the feature myself.
>
> At the moment, I’m in a better position to use an official release and
> report issues than maintain our own fork. Having access to the features I
> need gives me more incentive to upgrade, which makes adoption easier.
>
> Would introducing a 5.1 branch help get some new features out sooner? That
> would allow users like me to start taking advantage of them. Deciding when
> to move to 6.0 could then be part of the vote if additional features come
> along that need backporting.
>
> This whole discussion also makes me want to get more involved in the
> community. I’m not contributing code yet, but that’s definitely a goal for
> me. As I find more ways to share my time and experience, I’d like to be
> more vocal and engaged. It feels like a good way to ground myself and start
> giving back where I can.
>
>
>
>

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

[Josh McKenzie <jm...@apache.org>]

> 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 <jm...@apache.org> escribió:
>> 
>> I'll take a crack at those questions Dinesh:
>> 
>>> 1. What branch would be designated as a backports branch?
>> A new branch ( `cassandra-5.1` ) should be created. While reusing `cassandra-5.0` reduces overhead, changing the identity of a GA release mid-lifecycle risks breaking user trust (Isaac's point holds as foundational to me). We have no way of knowing how many operators rely on 5.0’s stability contract.
>> 
>>> 2. What are the tradeoffs of reusing an existing vs new branch?
>> *Reusing 5.0 (existing):*
>> *- Pros:* Lower maintenance burden (fewer merges, fewer releases, less CI).
>> *- Cons:* Violates the stability contract we put out for a GA release; erodes trust; risks destabilizing a widely deployed branch.
>> 
>> *New branch (5.1):*
>> *- Pros:* Preserves 5.0 as a true GA; creates clear separation between stable and community-backported features; aligns with OSS best practice / prior art
>> - *Cons:* Adds maintenance overhead (merges, CI, releases); lifecycle ambiguity (when does it EOL?); higher initial setup cost.
>> 
>>> 3. What would releases look like including release cadence?
>> "5.1.0-beta", "5.1.0-backport", "5.1.0-community"; some flag to denote "not regular GA".
>> Cadence: No fixed schedule (same as current GA). Reactive to feature merge or volume of smaller improvements, critical bugfixes, etc.
>> 
>>> 4. What would be the success criteria of this pilot?
>> - Increased community engagement (features backported in, releases cut); draw down of private forks
>> - More contributors stepping up as release managers to maintain this branch
>> - Multiple non-trivial production deployments using backport branch
>> - Acceptable stability and trust in the backport branch releases
>> 
>>> 5. What is the proposed time duration of the pilot?
>> 12 months, with quarterly [DISCUSS] retro check-ins on dev@.
>> 
>> If successful, we should consider evolving the model to: the latest GA release may accept community-approved backports. Only after proving the process works outside the GA branch first and only if we can signal this at the initial cut of the release.
>> 
>> 
>> On Thu, Oct 9, 2025, at 5:05 PM, Dinesh Joshi wrote:
>>> Wanted to recenter this conversation on the proposal and summarize my understanding –
>>> 
>>> 1. Our community wants a backports release and a stable release of cassandra.
>>> 2. Some operators would prefer to backports while others are ok waiting until the next major.
>>> 3. We are not talking about backporting all features only limited set of features in consultation with the broader community.
>>> 4. This is a limited time pilot.
>>> 
>>> Advantages:
>>> 1. We satisfy broader community needs.
>>> 2. By keeping backports and stable releases separate, we isolate risks to backports branch & release.
>>> 3. Limited time experiment allows us to adjust this approach including sunsetting it if we determine that we don't serve the community's need or excessive burden on maintainers.
>>> 4. Allows broader participation and growing the community.
>>> 
>>> Concerns:
>>> 1. Maintenance burden on existing maintainers - more releases, more artifacts, more targets to patch & merge.
>>> 2. Lack of sufficient release managers, maintainers, etc.
>>> 
>>> Mitigations:
>>> 
>>> Maintenance burden & lack of sufficient release managers – this is a broader pre-existing issue which will be exacerbated unless we get more people signed up for releases and maintaining. My expectation is that contributors who are enthusiastic about championing this proposal should commit to taking on that burden. I also expect that PMC members and Committers will sign up to support the contributors to make this successful. We will evaluate the success at the end of the pilot period and figure out the a way forward.
>>> 
>>> On Aleksey's point about just broadening the backporting criteria, I honestly have mixed feelings about this approach. In the past there has been a fear of destabilizing a released, stable branch so we limited the patches to security fixes and critical bug fixes. I am sure those concerns do still exist. Once we run this pilot, we will have a better understanding of the adoption rate of backports release vs stable release. If the data suggests that most people are comfortable taking backports release, we can revisit the project's governance and broaden the criteria. I would really like to defer making this decision until then.
>>> 
>>> If everybody is generally onboard with the proposal, we can start getting into the details of the logistics and I would suggest we circle back with more details which include -
>>> 
>>> 1. What branch would be designated as a backports branch?
>>> 2. What are the tradeoffs of reusing an existing vs new branch?
>>> 3. What would releases look like including release cadence?
>>> 4. What would be the success criteria of this pilot?
>>> 5. What is the proposed time duration of the pilot?
>>> 
>>> Thanks,
>>> 
>>> Dinesh
>>> 
>>> 
>>> On Thu, Oct 9, 2025 at 9:29 AM Patrick Lee <pa...@gmail.com> wrote:
>>>>> I wanted to share some thoughts from a user perspective on how we get features released sooner.
>>>>> 
>>>>> When 5.0 was released, there were statements like *“5.1 will be released very soon with even more features.”* At conferences and presentations, we showcase all these new capabilities, which drives a lot of excitement—but it often takes a while before those features are available in a release.
>>>>> 
>>>>> I really appreciate the stability of our releases and wouldn’t want to compromise that. Upgrading fleets takes time, and we don’t always jump on every new version immediately. That said, when I see features that help me, I adopt them quickly—at least for new deployments—to evaluate stability in our environment as we expand and upgrade.
>>>>> 
>>>>> Right now, I’m working on handling repairs differently than before. With CEP-37 in truck, I’m questioning how long I should wait. Why spend time implementing something else if Cassandra will soon support this? If I have to wait until 6.0, I have no idea how long that will take. My options become:
>>>>> 
>>>>>  1. Wait for the official release.
>>>>>  2. Build a temporary solution, knowing it’s short-lived.
>>>>>  3. Maintain an internal fork and backport the feature myself.
>>>>> At the moment, I’m in a better position to use an official release and report issues than maintain our own fork. Having access to the features I need gives me more incentive to upgrade, which makes adoption easier.
>>>>> 
>>>>> Would introducing a 5.1 branch help get some new features out sooner? That would allow users like me to start taking advantage of them. Deciding when to move to 6.0 could then be part of the vote if additional features come along that need backporting.
>>>>> 
>>>>> This whole discussion also makes me want to get more involved in the community. I’m not contributing code yet, but that’s definitely a goal for me. As I find more ways to share my time and experience, I’d like to be more vocal and engaged. It feels like a good way to ground myself and start giving back where I can.
>>>>> 
>> 

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

[Bernardo Botella <co...@bernardobotella.com>]

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 <jm...@apache.org>
> escribió:  
>  
>

> 
>
> I'll take a crack at those questions Dinesh:
>
>  
>
>

>> 1\. What branch would be designated as a backports branch?  
>
>
> A new branch ( `cassandra-5.1` ) should be created. While reusing
> `cassandra-5.0` reduces overhead, changing the identity of a GA release mid-
> lifecycle risks breaking user trust (Isaac's point holds as foundational to
> me). We have no way of knowing how many operators rely on 5.0’s stability
> contract.
>
>  
>
>

>> 2\. What are the tradeoffs of reusing an existing vs new branch?

>
>  **Reusing 5.0 (existing):**
>
>  _\- Pros:_ Lower maintenance burden (fewer merges, fewer releases, less
> CI).
>
>  _\- Cons:_ Violates the stability contract we put out for a GA release;
> erodes trust; risks destabilizing a widely deployed branch.  
>
>
>  
>
>
>  **New branch (5.1):**
>
>  _\- Pros:_ Preserves 5.0 as a true GA; creates clear separation between
> stable and community-backported features; aligns with OSS best practice /
> prior art
>
> \- _Cons:_ Adds maintenance overhead (merges, CI, releases); lifecycle
> ambiguity (when does it EOL?); higher initial setup cost.  
>
>
>  
>
>

>> 3\. What would releases look like including release cadence?  
>
>
> "5.1.0-beta", "5.1.0-backport", "5.1.0-community"; some flag to denote "not
> regular GA".
>
> Cadence: No fixed schedule (same as current GA). Reactive to feature merge
> or volume of smaller improvements, critical bugfixes, etc.  
>
>
>  
>
>

>> 4\. What would be the success criteria of this pilot?

>
> \- Increased community engagement (features backported in, releases cut);
> draw down of private forks
>
> \- More contributors stepping up as release managers to maintain this branch
>
> \- Multiple non-trivial production deployments using backport branch
>
> \- Acceptable stability and trust in the backport branch releases
>
>  
>
>

>> 5\. What is the proposed time duration of the pilot?

>
> 12 months, with quarterly [DISCUSS] retro check-ins on dev@.
>
>  
>
>
> If successful, we should consider evolving the model to: the latest GA
> release may accept community-approved backports. Only after proving the
> process works outside the GA branch first and only if we can signal this at
> the initial cut of the release.
>
>  
>
>
>  
>
>
> On Thu, Oct 9, 2025, at 5:05 PM, Dinesh Joshi wrote:
>

>> Wanted to recenter this conversation on the proposal and summarize my
understanding –

>>

>>  
>
>>

>> 1\. Our community wants a backports release and a stable release of
cassandra.

>>

>> 2\. Some operators would prefer to backports while others are ok waiting
until the next major.

>>

>> 3\. We are not talking about backporting all features only limited set of
features in consultation with the broader community.

>>

>> 4\. This is a limited time pilot.

>>

>>  
>
>>

>> Advantages:

>>

>> 1\. We satisfy broader community needs.

>>

>> 2\. By keeping backports and stable releases separate, we isolate risks to
backports branch & release.

>>

>> 3\. Limited time experiment allows us to adjust this approach including
sunsetting it if we determine that we don't serve the community's need or
excessive burden on maintainers.

>>

>> 4\. Allows broader participation and growing the community.

>>

>>  
>
>>

>> Concerns:

>>

>> 1\. Maintenance burden on existing maintainers - more releases, more
artifacts, more targets to patch & merge.

>>

>> 2\. Lack of sufficient release managers, maintainers, etc.

>>

>>  
>
>>

>> Mitigations:

>>

>>  
>
>>

>> Maintenance burden & lack of sufficient release managers – this is a
broader pre-existing issue which will be exacerbated unless we get more people
signed up for releases and maintaining. My expectation is that contributors
who are enthusiastic about championing this proposal should commit to taking
on that burden. I also expect that PMC members and Committers will sign up to
support the contributors to make this successful. We will evaluate the success
at the end of the pilot period and figure out the a way forward.

>>

>>  
>
>>

>> On Aleksey's point about just broadening the backporting criteria, I
honestly have mixed feelings about this approach. In the past there has been a
fear of destabilizing a released, stable branch so we limited the patches to
security fixes and critical bug fixes. I am sure those concerns do still
exist. Once we run this pilot, we will have a better understanding of the
adoption rate of backports release vs stable release. If the data suggests
that most people are comfortable taking backports release, we can revisit the
project's governance and broaden the criteria. I would really like to defer
making this decision until then.

>>

>>  
>
>>

>> If everybody is generally onboard with the proposal, we can start getting
into the details of the logistics and I would suggest we circle back with more
details which include -

>>

>>  
>
>>

>> 1\. What branch would be designated as a backports branch?

>>

>> 2\. What are the tradeoffs of reusing an existing vs new branch?

>>

>> 3\. What would releases look like including release cadence?

>>

>> 4\. What would be the success criteria of this pilot?

>>

>> 5\. What is the proposed time duration of the pilot?

>>

>>  
>
>>

>> Thanks,

>>

>>  
>
>>

>> Dinesh

>>

>>  
>
>>

>>  
>
>>

>> On Thu, Oct 9, 2025 at 9:29 AM Patrick Lee
<[patrickclee0207@gmail.com](mailto:patrickclee0207@gmail.com)> wrote:

>>

>>> > I wanted to share some thoughts from a user perspective on how we get
features released sooner.

>>>>

>>>> When 5.0 was released, there were statements like  _“5.1 will be released
very soon with even more features.”_  At conferences and presentations, we
showcase all these new capabilities, which drives a lot of excitement—but it
often takes a while before those features are available in a release.

>>>>

>>>> I really appreciate the stability of our releases and wouldn’t want to
compromise that. Upgrading fleets takes time, and we don’t always jump on
every new version immediately. That said, when I see features that help me, I
adopt them quickly—at least for new deployments—to evaluate stability in our
environment as we expand and upgrade.

>>>>

>>>> Right now, I’m working on handling repairs differently than before. With
CEP-37 in truck, I’m questioning how long I should wait. Why spend time
implementing something else if Cassandra will soon support this? If I have to
wait until 6.0, I have no idea how long that will take. My options become:

>>>>

>>>>   1. Wait for the official release.

>>>>   2. Build a temporary solution, knowing it’s short-lived.

>>>>   3. Maintain an internal fork and backport the feature myself.

>>>>

>>>>

>>>> At the moment, I’m in a better position to use an official release and
report issues than maintain our own fork. Having access to the features I need
gives me more incentive to upgrade, which makes adoption easier.

>>>>

>>>> Would introducing a 5.1 branch help get some new features out sooner?
That would allow users like me to start taking advantage of them. Deciding
when to move to 6.0 could then be part of the vote if additional features come
along that need backporting.

>>>>

>>>> This whole discussion also makes me want to get more involved in the
community. I’m not contributing code yet, but that’s definitely a goal for me.
As I find more ways to share my time and experience, I’d like to be more vocal
and engaged. It feels like a good way to ground myself and start giving back
where I can.

>
>  
>

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

[Alex Petrov <al...@coffeenco.de>]

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

Could you elaborate why a stable feature (TCM) is mentioned here alongside with a feature under development? 

Why specifically do you think TCM will keep everyone on 5.0/5.1?

The only concern I _ever_ heard voiced about TCM is that there's no downgrade path after you are already on TCM, but you _can_ downgrade to the previous major version without any problem (see [1], which includes CCM test script which shows the downgrade path working), even after doing schema changes & a host replacement _after_ initializing the CMS.

> I'll be the person to say it outloud

Could you elaborate on what concerns you've heard?  Do you mean there's wider unspoken concern in the community about upgrading to TCM? I'm curious if there's feedback I've missed.
 
Thanks
--Alex

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

On Sun, Oct 12, 2025, at 5:28 PM, Chris Lohfink wrote:
>> 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

[Štefan Miklošovič <sm...@apache.org>]

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 <al...@coffeenco.de> 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, scott@paradoxica.net 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 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.
> – 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.
> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
> – Backports branches don’t solve the “some people run forks” problem.
> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>
> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>
> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>
> – 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.
> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>
> – Scott
>
> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>
> 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

[Alex Petrov <al...@coffeenco.de>]

> 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, scott@paradoxica.net 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 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.
>> – 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.
>> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
>> – Backports branches don’t solve the “some people run forks” problem.
>> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>> 
>> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>> 
>> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>> 
>> – 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.
>> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
>> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>> 
>> – Scott
>> 
>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>> 
>>>> 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

[Michael Shuler <mi...@pbandjelly.org>]

I wanted to add context from a well-proven, much-discussed and changed 
over the years, Debian Backports system for policy ideas, repo or branch 
layout ..as a higher level question - is this a sub-project or in-tree? 
- yessir indeed, it requires enthusiast committers that need to scratch 
an itch, in the end. This is gemini's regurgitation on Debian Backports 
history with some links for more info:

The Debian Backports repository originated as an unofficial project, 
backports.org, created to address the need for newer software versions 
within the stable Debian release. In 2010, the project became an 
official Debian service, providing a balance between the stability of 
the core system and the benefits of newer features. [1, 2, 3, 4, 5]

Backports history timeline

• Early days (pre-2010): The Backports project existed as an independent 
service named backports.org, run by Debian developers and volunteers.

         • Goal: The repository was created for users who preferred the 
security and stability of the official Debian Stable release but still 
required certain newer applications from Testing or Unstable.
         • Packages: It provided precompiled packages for the current 
Stable release, containing software versions that would be available in 
the next Stable version.
         • Unofficial status: Since it was not an official Debian 
service, the packages were not as rigorously tested as those in the 
Stable repository and came with a disclaimer about potential 
incompatibility.

• September 5, 2010: Backports becomes official

         • Following an announcement, the project was officially adopted 
by the Debian project and migrated to the `backports.debian.org` domain.
         • Repository change: Users were instructed to update their 
`sources.list` file from `backports.org` to the new 
`deb.debian.org/debian` address.
         • Policy and testing: The backports policy was formalized. 
Packages would continue to be rebuilt from the Debian Testing branch, 
but with stricter guidelines to ensure compatibility and minimize the 
risk of breaking the stable system. For example, backports of core 
libraries that would disrupt the stable system are not permitted.

• 2011: Backports development evolves

         • Snapshot archive: The `snapshot.debian.org` service, which 
archived the Backports repository and others, was publicly announced in 
April 2010. By September, the `backports.org` repository was officially 
renamed to `debian-backports`.
         • Early kernel backport: In July, a discussion on the Unix 
Stack Exchange highlighted the importance of a backport kernel in Debian 
6 "Squeeze," emphasizing the value for users with newer hardware 
requiring updated drivers not available in the stable kernel.

• 2019: Introduction of "sloppy" backports

         • For the Debian 12 ("Bookworm") cycle, a new suite named 
`bookworm-backports-sloppy` was introduced.
         • Purpose: This repository offered even newer packages from the 
Testing distribution than standard backports.
         • Warning: It came with a stronger warning about potential 
instability, sacrificing a clean upgrade path for the newest available 
software.

• Present day (2024–2025): Backports structure

         • Current suites: The modern Backports repository provides 
several suites for the latest releases. For example, at the time of 
writing (late 2025), `trixie-backports` provides packages for Debian 13 
"Trixie".
         • Oldstable support: A backports suite for the previous Stable 
release ("oldstable") is maintained for one year after the new Stable 
release. For example, `bullseye-backports` was closed on June 10, 2024, 
one year after Debian 12 "Bookworm" was released. [1, 2, 6, 7, 8, 9, 10]

[1] https://wiki.debian.org/Backports
[2] https://wiki.debian.org/Backports
[3] https://backports.debian.org/
[4] https://www.lenovo.com/ca/en/glossary/debian/
[5] https://wiki.debian.org/Glossary
[6] https://backports.debian.org/Instructions/
[7] https://snapshot.debian.org/
[8] https://backports.debian.org/Instructions/
[9] https://unix.stackexchange.com/questions/16781/why-is-there-a-debian-backport-of-linux-kernel
[10] https://forums.debian.net/viewtopic.php?t=3220

-- 
Kind regards,
Michael


On 10/13/25 19:35, Jaydeep Chovatia wrote:
> 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 
> <calebrackliffe@gmail.com <ma...@gmail.com>> 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 <mck@apache.org
>     <ma...@apache.org>> wrote:
> 
> 
> 
>          > On 13 Oct 2025, at 20:13, Štefan Miklošovič
>         <smiklosovic@apache.org <ma...@apache.org>> 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

[Jaydeep Chovatia <ch...@gmail.com>]

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 <ca...@gmail.com>
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 <mc...@apache.org> wrote:
>
>>
>>
>> > On 13 Oct 2025, at 20:13, Štefan Miklošovič <sm...@apache.org>
>> 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

[Caleb Rackliffe <ca...@gmail.com>]

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 <mc...@apache.org> wrote:

>
>
> > On 13 Oct 2025, at 20:13, Štefan Miklošovič <sm...@apache.org>
> 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

[Mick <mc...@apache.org>]

> On 13 Oct 2025, at 20:13, Štefan Miklošovič <sm...@apache.org> 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

[Alex Petrov <al...@coffeenco.de>]

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 <dj...@apache.org> 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 <ca...@gmail.com> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Caleb Rackliffe <ca...@gmail.com>]

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 <jm...@apache.org> 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 <dj...@apache.org> 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 <ca...@gmail.com>
> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
> >
> >
> >
> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org>
> 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

[Josh McKenzie <jm...@apache.org>]

> 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 <dj...@apache.org> 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 <ca...@gmail.com> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Josh McKenzie <jm...@apache.org>]

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 <dj...@apache.org> 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 <ca...@gmail.com> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Patrick McFadin <pm...@gmail.com>]

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 <jj...@gmail.com> 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 <pm...@gmail.com> 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 <dj...@apache.org> 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 <
>> calebrackliffe@gmail.com> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org>
>>> 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

[Jeff Jirsa <jj...@gmail.com>]

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 <pm...@gmail.com> 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 <djoshi@apache.org <ma...@apache.org>> 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 <calebrackliffe@gmail.com <ma...@gmail.com>> 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 <alexp@coffeenco.de <ma...@coffeenco.de>> 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 <alexp@coffeenco.de <ma...@coffeenco.de>> 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 <jjirsa@gmail.com <ma...@gmail.com>> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jmckenzie@apache.org <ma...@apache.org>> 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

[Patrick McFadin <pm...@gmail.com>]

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 <dj...@apache.org> 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 <ca...@gmail.com>
> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
>> >
>> >
>> >
>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org>
>> 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

[Alex Petrov <al...@coffeenco.de>]

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 <ca...@gmail.com> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
>>>> >
>>>> >
>>>> >
>>>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Dinesh Joshi <dj...@apache.org>]

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 <ca...@gmail.com>
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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
> >
> >
> >
> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org>
> 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

[Alex Petrov <al...@coffeenco.de>]

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 <ca...@gmail.com> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
>>>> >
>>>> >
>>>> >
>>>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Jeremiah Jordan <je...@apache.org>]

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 <ca...@gmail.com>
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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
> >
> >
> >
> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org>
> 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

[Caleb Rackliffe <ca...@gmail.com>]

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 <al...@coffeenco.de> 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
<[alexp@coffeenco.de](mailto:alexp@coffeenco.de)> 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
<[jjirsa@gmail.com](mailto:jjirsa@gmail.com)> wrote:

>>

>> >

>>

>> >

>>

>> >

>>

>> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie
<[jmckenzie@apache.org](mailto:jmckenzie@apache.org)> 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

[Alex Petrov <al...@coffeenco.de>]

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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
> >
> >
> >
> > > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Štefan Miklošovič <sm...@apache.org>]

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 <al...@coffeenco.de> 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 <jj...@gmail.com> wrote:
>
>
>
> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Alex Petrov <al...@coffeenco.de>]

> 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 <jj...@gmail.com> wrote:
>> 
>> 
>> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Caleb Rackliffe <ca...@gmail.com>]

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č <sm...@apache.org>
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 <jm...@apache.org>
> 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 <jj...@gmail.com> wrote:
>>
>>
>>
>> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org>
>> 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

[Štefan Miklošovič <sm...@apache.org>]

> 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 <jm...@apache.org> 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 <jj...@gmail.com> wrote:
>
>
>
> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Josh McKenzie <jm...@apache.org>]

> 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 <jj...@gmail.com> wrote:
>> 
>> 
>> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Štefan Miklošovič <sm...@apache.org>]

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 <jj...@gmail.com> wrote:

>
>
> > On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Jeff Jirsa <jj...@gmail.com>]

> On Oct 13, 2025, at 7:02 AM, Josh McKenzie <jm...@apache.org> 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

[Josh McKenzie <jm...@apache.org>]

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, scott@paradoxica.net 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 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.
> – 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.
> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
> – Backports branches don’t solve the “some people run forks” problem.
> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
> 
> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
> 
> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
> 
> – 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.
> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
> 
> – Scott
> 
>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>> 
>>> 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

[Caleb Rackliffe <ca...@gmail.com>]

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 <ca...@gmail.com>
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 <
> chovatia.jaydeep@gmail.com> 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 <sc...@paradoxica.net> 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 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.
>>> – 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.
>>> – Pitching this as a limited-time pilot doesn't these problems, and it
>>> introduces new ones. The user community would fragment across these
>>> branches and have to be reconverged despite untested upgrade paths if the
>>> pilot were wound down.
>>> – Backports branches don’t solve the “some people run forks” problem.
>>> – Backports branches don’t solve the user community adoption problem
>>> either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>>
>>> For me, the proposal wouldn't achieve its stated goal and introduces
>>> many new issues. But I do strongly support that goal.
>>>
>>> Toward bringing stable features into the user community’s hands more
>>> quickly, the fix for this seems like:
>>>
>>> – 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.
>>> – Increasing release velocity. We do need to improve here and I’d be
>>> open to 5.1.
>>> – Exercising our existing consensus-based approach of backporting stable
>>> and well-contained enhancements to earlier branches following discussion on
>>> the mailing list. We could do this a little more often.
>>>
>>> – Scott
>>>
>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>>
>>> 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

[Caleb Rackliffe <ca...@gmail.com>]

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 <ch...@gmail.com>
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 <sc...@paradoxica.net> 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 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.
>> – 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.
>> – Pitching this as a limited-time pilot doesn't these problems, and it
>> introduces new ones. The user community would fragment across these
>> branches and have to be reconverged despite untested upgrade paths if the
>> pilot were wound down.
>> – Backports branches don’t solve the “some people run forks” problem.
>> – Backports branches don’t solve the user community adoption problem
>> either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>
>> For me, the proposal wouldn't achieve its stated goal and introduces many
>> new issues. But I do strongly support that goal.
>>
>> Toward bringing stable features into the user community’s hands more
>> quickly, the fix for this seems like:
>>
>> – 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.
>> – Increasing release velocity. We do need to improve here and I’d be open
>> to 5.1.
>> – Exercising our existing consensus-based approach of backporting stable
>> and well-contained enhancements to earlier branches following discussion on
>> the mailing list. We could do this a little more often.
>>
>> – Scott
>>
>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>
>> 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

[Alex Petrov <al...@coffeenco.de>]

> (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 <jm...@apache.org>
>> *Date: *Wednesday, 15 October 2025 at 14:13
>> *To: *dev <de...@cassandra.apache.org>
>> *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 <ch...@gmail.com> 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 <ne...@gmail.com> 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 <ch...@gmail.com> 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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
>>>>>>>>> – 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.
>>>>>>>>> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
>>>>>>>>> – Backports branches don’t solve the “some people run forks” problem.
>>>>>>>>> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>>>>>>>>  
>>>>>>>>> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>>>>>>>>>  
>>>>>>>>> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>>>>>>>>>  
>>>>>>>>> – 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.
>>>>>>>>> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
>>>>>>>>> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>>>>>>>>>  
>>>>>>>>> – Scott
>>>>>>>>>  
>>>>>>>>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>>>>>>>>>  
>>>>>>>>>>> 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
>>>>>>>  
>>>>>  
>>>>>  
>>>>> --
>>>>> Dmitry Konstantinov
>>  
> 

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

[Josh McKenzie <jm...@apache.org>]

> 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 <jm...@apache.org>
> *Date: *Wednesday, 15 October 2025 at 14:13
> *To: *dev <de...@cassandra.apache.org>
> *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 <ch...@gmail.com> 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 <ne...@gmail.com> 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 <ch...@gmail.com> 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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
>>>>>>>> – 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.
>>>>>>>> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
>>>>>>>> – Backports branches don’t solve the “some people run forks” problem.
>>>>>>>> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>>>>>>>  
>>>>>>>> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>>>>>>>>  
>>>>>>>> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>>>>>>>>  
>>>>>>>> – 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.
>>>>>>>> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
>>>>>>>> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>>>>>>>>  
>>>>>>>> – Scott
>>>>>>>>  
>>>>>>>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>>>>>>>>  
>>>>>>>>>> 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
>>>>>>  
>>>>  
>>>>  
>>>> --
>>>> Dmitry Konstantinov
>  

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

[Dinesh Joshi <dj...@apache.org>]

On Thu, Oct 16, 2025 at 7:41 AM Josh McKenzie <jm...@apache.org> wrote:

>
>    1. We as a community collaborated on CEP-21 (TCM)
>    <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata>,
>    discussed it
>    <https://lists.apache.org/thread/h25skwkbdztz9hj2pxtgh39rnjfzckk7>,
>    and voted to approve it
>    <https://lists.apache.org/thread/0lk0yll0mkd7858hqndqjgcyz3bgxkoz>
>       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

[Josh McKenzie <jm...@apache.org>]

First off: thanks everyone for all the great engagement here. This has been a very educational thread. :)

We're past 100 replies so I think we need to put a bow on at least this thread. Or we need to edit it and publish it as a novella. I vote the former.

What I'm taking away from this (the following summary is limited to only views expressed in this thread):
 • A majority of people support sooner feature availability *of low-risk features. *This thread has talked about backports as the mechanism for that.
 • There are a variety of motivations
 • There are a variety of ideas about form (backport branch, backport to latest GA, relax select backports to any GA branch)
 • There are concerns that formalizing a backport branch will discourage people from qualifying trunk, which secondarily implies the latest GA releases from trunk
 • There are concerns that formalizing a backport branch will open the floodgates to backport a ton of stuff
I'm going to step away from just trying to moderate the discussion now to participate and editorialize: I think we need to ask: "Why have people run backport branches in the past and why are they still running them now?" Making backporting public and easier is almost certainly not the only solution to this if we all agree that effort is not best spent backporting features to private forks, and secondarily public branches.

My personal understanding on the history of "Why Private Backport Forks?" on our project goes something like the following:
 1. *One Way Street Risks:*
   1. Thrift was removed and people still needed it
   2. Storage engine optimizations and rewrite led to a long tail of instability (improving a house built on a bed of sand is still on a bed of sand)
   3. A multi-year freeze of new features meant "Life Finds a Way"
   4. Concerns about how to safely qualify TCM (Chris expressed that in this thread, but that feature has not yet been released so nobody is running a backport branch today based on this)
 2. *There is too much time between major releases* and there are valuable features people are working on that are production ready and they need them sooner. If you write a feature internally and roll it out to prod then upstream to trunk, there's a good chance you're going to have to wait a couple years to have a GA release with that feature available in it.
So re: *One Way Street Risks:*
 1. We agreed in another discussion since to try very hard to not remove things going forward
 2. We as a community collaborated on CEP-21 (TCM) <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata>, discussed it <https://lists.apache.org/thread/h25skwkbdztz9hj2pxtgh39rnjfzckk7>, and voted to approve it <https://lists.apache.org/thread/0lk0yll0mkd7858hqndqjgcyz3bgxkoz>
   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)
I view the core tension of this category of backport incentives as a "tax" due to our past methods - we've formalized moving away from this approach to engineering. In a future where new features are optional, behind a feature flag, and disabled by default, stability will be improved and qualification much smoother (which is why we all agreed to that path going forward).

Re: *Too Much Time Between Releases,* I've been agitating for awhile that:
 1. We need to release regularly on a yearly cadence, and
 2. I think we should cut alphas from trunk once a quarter
I think this thread has also shown a general consensus we can add a:
 • 3. We should be more lenient on what we allow backports on to existing GA branches. For example:
   • Perf fixes that are so severe they're arguably bugfixes
   • Operational improvements that are well isolated like CEP-37
   • Probably some other things we should discuss in another thread because 100+ emails is Too Many Emails
I propose our concrete next steps should be independent follow-up discussions on (sequential, not in parallel; 1 discussion at a time):
 1. Refinements to our decision-tree around backports
 2. Exploration on *why* people have long-running private fork backport branches and brainstorming different options on how to address that
 3. Refining and formalizing our "Definition of Done" (to expose a feature to users, not to block merge)
~Josh

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 <jm...@apache.org>
> *Date: *Wednesday, 15 October 2025 at 14:13
> *To: *dev <de...@cassandra.apache.org>
> *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 <ch...@gmail.com> 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 <ne...@gmail.com> 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 <ch...@gmail.com> 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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
>>>>>>>> – 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.
>>>>>>>> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
>>>>>>>> – Backports branches don’t solve the “some people run forks” problem.
>>>>>>>> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>>>>>>>  
>>>>>>>> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>>>>>>>>  
>>>>>>>> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>>>>>>>>  
>>>>>>>> – 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.
>>>>>>>> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
>>>>>>>> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>>>>>>>>  
>>>>>>>> – Scott
>>>>>>>>  
>>>>>>>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>>>>>>>>  
>>>>>>>>>> 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
>>>>>>  
>>>>  
>>>>  
>>>> --
>>>> Dmitry Konstantinov
>  

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

["Miklosovic, Stefan via dev" <de...@cassandra.apache.org>]

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 <jm...@apache.org>
Date: Wednesday, 15 October 2025 at 14:13
To: dev <de...@cassandra.apache.org>
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 <ch...@gmail.com>> 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 <ne...@gmail.com>> 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 <ch...@gmail.com>> 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 <al...@coffeenco.de>> 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 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 <sc...@paradoxica.net>> 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 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.
– 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.
– Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
– Backports branches don’t solve the “some people run forks” problem.
– Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.

For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.

Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:

– 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.
– Increasing release velocity. We do need to improve here and I’d be open to 5.1.
– Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.

– Scott

On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com>> wrote:

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



--
Dmitry Konstantinov

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

[Josh McKenzie <jm...@apache.org>]

> 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 <ch...@gmail.com> 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 <ne...@gmail.com> 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 <ch...@gmail.com> 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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
>>>>>>> – 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.
>>>>>>> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
>>>>>>> – Backports branches don’t solve the “some people run forks” problem.
>>>>>>> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>>>>>> 
>>>>>>> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>>>>>>> 
>>>>>>> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>>>>>>> 
>>>>>>> – 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.
>>>>>>> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
>>>>>>> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>>>>>>> 
>>>>>>> – Scott
>>>>>>> 
>>>>>>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> 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
>>>>> 
>>> 
>>> 
>>> --
>>> Dmitry Konstantinov

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

[Caleb Rackliffe <ca...@gmail.com>]

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 <ch...@gmail.com>
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 <ne...@gmail.com>
> 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 <
>> chovatia.jaydeep@gmail.com> 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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
>>>> – 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.
>>>> – Pitching this as a limited-time pilot doesn't these problems, and it
>>>> introduces new ones. The user community would fragment across these
>>>> branches and have to be reconverged despite untested upgrade paths if the
>>>> pilot were wound down.
>>>> – Backports branches don’t solve the “some people run forks” problem.
>>>> – Backports branches don’t solve the user community adoption problem
>>>> either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>>>
>>>> For me, the proposal wouldn't achieve its stated goal and introduces
>>>> many new issues. But I do strongly support that goal.
>>>>
>>>> Toward bringing stable features into the user community’s hands more
>>>> quickly, the fix for this seems like:
>>>>
>>>> – 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.
>>>> – Increasing release velocity. We do need to improve here and I’d be
>>>> open to 5.1.
>>>> – Exercising our existing consensus-based approach of backporting
>>>> stable and well-contained enhancements to earlier branches following
>>>> discussion on the mailing list. We could do this a little more often.
>>>>
>>>> – Scott
>>>>
>>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com>
>>>> wrote:
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>
>> --
>> Dmitry Konstantinov
>>
>

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

[Jaydeep Chovatia <ch...@gmail.com>]

>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 <ne...@gmail.com>
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 <ch...@gmail.com>
> 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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
>>> – 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.
>>> – Pitching this as a limited-time pilot doesn't these problems, and it
>>> introduces new ones. The user community would fragment across these
>>> branches and have to be reconverged despite untested upgrade paths if the
>>> pilot were wound down.
>>> – Backports branches don’t solve the “some people run forks” problem.
>>> – Backports branches don’t solve the user community adoption problem
>>> either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>>
>>> For me, the proposal wouldn't achieve its stated goal and introduces
>>> many new issues. But I do strongly support that goal.
>>>
>>> Toward bringing stable features into the user community’s hands more
>>> quickly, the fix for this seems like:
>>>
>>> – 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.
>>> – Increasing release velocity. We do need to improve here and I’d be
>>> open to 5.1.
>>> – Exercising our existing consensus-based approach of backporting stable
>>> and well-contained enhancements to earlier branches following discussion on
>>> the mailing list. We could do this a little more often.
>>>
>>> – Scott
>>>
>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>>
>>> 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
>>>
>>>
>>>
>
> --
> Dmitry Konstantinov
>

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

[Dmitry Konstantinov <ne...@gmail.com>]

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 <ch...@gmail.com>
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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
>> – 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.
>> – Pitching this as a limited-time pilot doesn't these problems, and it
>> introduces new ones. The user community would fragment across these
>> branches and have to be reconverged despite untested upgrade paths if the
>> pilot were wound down.
>> – Backports branches don’t solve the “some people run forks” problem.
>> – Backports branches don’t solve the user community adoption problem
>> either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>>
>> For me, the proposal wouldn't achieve its stated goal and introduces many
>> new issues. But I do strongly support that goal.
>>
>> Toward bringing stable features into the user community’s hands more
>> quickly, the fix for this seems like:
>>
>> – 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.
>> – Increasing release velocity. We do need to improve here and I’d be open
>> to 5.1.
>> – Exercising our existing consensus-based approach of backporting stable
>> and well-contained enhancements to earlier branches following discussion on
>> the mailing list. We could do this a little more often.
>>
>> – Scott
>>
>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>
>> 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
>>
>>
>>

-- 
Dmitry Konstantinov

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

[Jaydeep Chovatia <ch...@gmail.com>]

>@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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
> – 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.
> – Pitching this as a limited-time pilot doesn't these problems, and it
> introduces new ones. The user community would fragment across these
> branches and have to be reconverged despite untested upgrade paths if the
> pilot were wound down.
> – Backports branches don’t solve the “some people run forks” problem.
> – Backports branches don’t solve the user community adoption problem
> either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>
> For me, the proposal wouldn't achieve its stated goal and introduces many
> new issues. But I do strongly support that goal.
>
> Toward bringing stable features into the user community’s hands more
> quickly, the fix for this seems like:
>
> – 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.
> – Increasing release velocity. We do need to improve here and I’d be open
> to 5.1.
> – Exercising our existing consensus-based approach of backporting stable
> and well-contained enhancements to earlier branches following discussion on
> the mailing list. We could do this a little more often.
>
> – Scott
>
> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>
> 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

[Josh McKenzie <jm...@apache.org>]

> 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 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č <sm...@apache.org> 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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
>> > – 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.
>> > – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
>> > – Backports branches don’t solve the “some people run forks” problem.
>> > – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>> >
>> > For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>> >
>> > Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>> >
>> > – 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.
>> > – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
>> > – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>> >
>> > – Scott
>> >
>> > On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>> >
>> > 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

[Michael Burman <ya...@iki.fi>]

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č <sm...@apache.org>
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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
> > – 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.
> > – Pitching this as a limited-time pilot doesn't these problems, and it
> introduces new ones. The user community would fragment across these
> branches and have to be reconverged despite untested upgrade paths if the
> pilot were wound down.
> > – Backports branches don’t solve the “some people run forks” problem.
> > – Backports branches don’t solve the user community adoption problem
> either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
> >
> > For me, the proposal wouldn't achieve its stated goal and introduces
> many new issues. But I do strongly support that goal.
> >
> > Toward bringing stable features into the user community’s hands more
> quickly, the fix for this seems like:
> >
> > – 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.
> > – Increasing release velocity. We do need to improve here and I’d be
> open to 5.1.
> > – Exercising our existing consensus-based approach of backporting stable
> and well-contained enhancements to earlier branches following discussion on
> the mailing list. We could do this a little more often.
> >
> > – Scott
> >
> > On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
> >
> > 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

[Štefan Miklošovič <sm...@apache.org>]

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 <al...@coffeenco.de> 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 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 <sc...@paradoxica.net> 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 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.
> – 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.
> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
> – Backports branches don’t solve the “some people run forks” problem.
> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>
> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>
> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>
> – 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.
> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>
> – Scott
>
> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>
> 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

[Alex Petrov <al...@coffeenco.de>]

> 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 <sc...@paradoxica.net> 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 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.
>> – 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.
>> – Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
>> – Backports branches don’t solve the “some people run forks” problem.
>> – Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>> 
>> For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.
>> 
>> Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:
>> 
>> – 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.
>> – Increasing release velocity. We do need to improve here and I’d be open to 5.1.
>> – Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.
>> 
>> – Scott
>> 
>>> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>>> 
>>>> 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

[Jaydeep Chovatia <ch...@gmail.com>]

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 <sc...@paradoxica.net> 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 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.
> – 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.
> – Pitching this as a limited-time pilot doesn't these problems, and it
> introduces new ones. The user community would fragment across these
> branches and have to be reconverged despite untested upgrade paths if the
> pilot were wound down.
> – Backports branches don’t solve the “some people run forks” problem.
> – Backports branches don’t solve the user community adoption problem
> either, unless we’re also publishing per-OS packages, Maven artifacts, etc.
>
> For me, the proposal wouldn't achieve its stated goal and introduces many
> new issues. But I do strongly support that goal.
>
> Toward bringing stable features into the user community’s hands more
> quickly, the fix for this seems like:
>
> – 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.
> – Increasing release velocity. We do need to improve here and I’d be open
> to 5.1.
> – Exercising our existing consensus-based approach of backporting stable
> and well-contained enhancements to earlier branches following discussion on
> the mailing list. We could do this a little more often.
>
> – Scott
>
> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
>
> 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

[sc...@paradoxica.net]

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 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.
– 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.
– Pitching this as a limited-time pilot doesn't these problems, and it introduces new ones. The user community would fragment across these branches and have to be reconverged despite untested upgrade paths if the pilot were wound down.
– Backports branches don’t solve the “some people run forks” problem.
– Backports branches don’t solve the user community adoption problem either, unless we’re also publishing per-OS packages, Maven artifacts, etc.

For me, the proposal wouldn't achieve its stated goal and introduces many new issues. But I do strongly support that goal.

Toward bringing stable features into the user community’s hands more quickly, the fix for this seems like:

– 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.
– Increasing release velocity. We do need to improve here and I’d be open to 5.1.
– Exercising our existing consensus-based approach of backporting stable and well-contained enhancements to earlier branches following discussion on the mailing list. We could do this a little more often.

– Scott

> On Oct 12, 2025, at 8:28 AM, Chris Lohfink <cl...@gmail.com> wrote:
> 
>> 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

[Chris Lohfink <cl...@gmail.com>]

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

[Josh McKenzie <jm...@apache.org>]

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 <dj...@apache.org> wrote:
> > 
> > On Sat, Oct 11, 2025 at 4:48 AM Josh McKenzie <jm...@apache.org> 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

[Mick <mc...@apache.org>]

> On 11 Oct 2025, at 19:00, Dinesh Joshi <dj...@apache.org> wrote:
> 
> On Sat, Oct 11, 2025 at 4:48 AM Josh McKenzie <jm...@apache.org> 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

[Dinesh Joshi <dj...@apache.org>]

On Sat, Oct 11, 2025 at 4:48 AM Josh McKenzie <jm...@apache.org> 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

[Josh McKenzie <jm...@apache.org>]

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 <pa...@gmail.com> wrote:
>>> I wanted to share some thoughts from a user perspective on how we get features released sooner.
>>> 
>>> When 5.0 was released, there were statements like *“5.1 will be released very soon with even more features.”* At conferences and presentations, we showcase all these new capabilities, which drives a lot of excitement—but it often takes a while before those features are available in a release.
>>> 
>>> I really appreciate the stability of our releases and wouldn’t want to compromise that. Upgrading fleets takes time, and we don’t always jump on every new version immediately. That said, when I see features that help me, I adopt them quickly—at least for new deployments—to evaluate stability in our environment as we expand and upgrade.
>>> 
>>> Right now, I’m working on handling repairs differently than before. With CEP-37 in truck, I’m questioning how long I should wait. Why spend time implementing something else if Cassandra will soon support this? If I have to wait until 6.0, I have no idea how long that will take. My options become:
>>> 
>>>  1. Wait for the official release.
>>>  2. Build a temporary solution, knowing it’s short-lived.
>>>  3. Maintain an internal fork and backport the feature myself.
>>> At the moment, I’m in a better position to use an official release and report issues than maintain our own fork. Having access to the features I need gives me more incentive to upgrade, which makes adoption easier.
>>> 
>>> Would introducing a 5.1 branch help get some new features out sooner? That would allow users like me to start taking advantage of them. Deciding when to move to 6.0 could then be part of the vote if additional features come along that need backporting.
>>> 
>>> This whole discussion also makes me want to get more involved in the community. I’m not contributing code yet, but that’s definitely a goal for me. As I find more ways to share my time and experience, I’d like to be more vocal and engaged. It feels like a good way to ground myself and start giving back where I can.
>>> 

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

[Dinesh Joshi <dj...@apache.org>]

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 <pa...@gmail.com>
wrote:

> I wanted to share some thoughts from a user perspective on how we get
>> features released sooner.
>>
>> When 5.0 was released, there were statements like *“5.1 will be released
>> very soon with even more features.”* At conferences and presentations,
>> we showcase all these new capabilities, which drives a lot of
>> excitement—but it often takes a while before those features are available
>> in a release.
>>
>> I really appreciate the stability of our releases and wouldn’t want to
>> compromise that. Upgrading fleets takes time, and we don’t always jump on
>> every new version immediately. That said, when I see features that help me,
>> I adopt them quickly—at least for new deployments—to evaluate stability in
>> our environment as we expand and upgrade.
>>
>> Right now, I’m working on handling repairs differently than before. With
>> CEP-37 in truck, I’m questioning how long I should wait. Why spend time
>> implementing something else if Cassandra will soon support this? If I have
>> to wait until 6.0, I have no idea how long that will take. My options
>> become:
>>
>>    1. Wait for the official release.
>>    2. Build a temporary solution, knowing it’s short-lived.
>>    3. Maintain an internal fork and backport the feature myself.
>>
>> At the moment, I’m in a better position to use an official release and
>> report issues than maintain our own fork. Having access to the features I
>> need gives me more incentive to upgrade, which makes adoption easier.
>>
>> Would introducing a 5.1 branch help get some new features out sooner?
>> That would allow users like me to start taking advantage of them. Deciding
>> when to move to 6.0 could then be part of the vote if additional features
>> come along that need backporting.
>>
>> This whole discussion also makes me want to get more involved in the
>> community. I’m not contributing code yet, but that’s definitely a goal for
>> me. As I find more ways to share my time and experience, I’d like to be
>> more vocal and engaged. It feels like a good way to ground myself and start
>> giving back where I can.
>>
>

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

[Patrick Lee <pa...@gmail.com>]

>
> I wanted to share some thoughts from a user perspective on how we get
> features released sooner.
>
> When 5.0 was released, there were statements like *“5.1 will be released
> very soon with even more features.”* At conferences and presentations, we
> showcase all these new capabilities, which drives a lot of excitement—but
> it often takes a while before those features are available in a release.
>
> I really appreciate the stability of our releases and wouldn’t want to
> compromise that. Upgrading fleets takes time, and we don’t always jump on
> every new version immediately. That said, when I see features that help me,
> I adopt them quickly—at least for new deployments—to evaluate stability in
> our environment as we expand and upgrade.
>
> Right now, I’m working on handling repairs differently than before. With
> CEP-37 in truck, I’m questioning how long I should wait. Why spend time
> implementing something else if Cassandra will soon support this? If I have
> to wait until 6.0, I have no idea how long that will take. My options
> become:
>
>    1. Wait for the official release.
>    2. Build a temporary solution, knowing it’s short-lived.
>    3. Maintain an internal fork and backport the feature myself.
>
> At the moment, I’m in a better position to use an official release and
> report issues than maintain our own fork. Having access to the features I
> need gives me more incentive to upgrade, which makes adoption easier.
>
> Would introducing a 5.1 branch help get some new features out sooner? That
> would allow users like me to start taking advantage of them. Deciding when
> to move to 6.0 could then be part of the vote if additional features come
> along that need backporting.
>
> This whole discussion also makes me want to get more involved in the
> community. I’m not contributing code yet, but that’s definitely a goal for
> me. As I find more ways to share my time and experience, I’d like to be
> more vocal and engaged. It feels like a good way to ground myself and start
> giving back where I can.
>

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

[Aleksey Yeshchenko <al...@apple.com>]

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 <jm...@apache.org> 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: 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 <http://pre-ci.cassandra.apache.org/> <http://pre-ci.cassandra.apache.org <http://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 upgrade process easier for users.)  
>> > 
>> >  - 5.1 needs to be maintained past 6.0 GA's date (Jeremiah, Isaac).  Continuing on from above.  Users need a window to upgrade from 5.1 to 6.0, so there has to be an overlap anyway.  But I can imagine, and maybe some downstream users involved here can answer this, that part of the value of this pilot is that specific dev features in trunk might be a lot harder to upgrade to than we realise– that it takes ~years to adjust fleets of production clusters to certain new features in the next major, while other features are just about back porting but provide value that's simply unjustifiable for a business to look past (and is what keeps C* being part of the tech stack in those companies).  A 5.1 branch might also serve purpose in providing specific features that help make the upgrade to the next major possible/feasible (like support for a blue-green upgrade solution), but this is purely speculative.
>> > 
>> >  - How other projects are doing it and their past discussions on what they decided (Ekaterina).  I agree with this– we should reference what they are doing and why (but also not presume that's how they would do it again today).  Do we know any folk active in any of those projects ? 
>> > 
>> > 
>> > So FTR, based on the discussion so far, I'm really not keen of softening what goes into 5.0.x, finding having to work on bugs in our stable branches sometimes hard work, if not at times quite stressful, I really appreciate all efforts in maintaining their hardness.   I see the risk of production clusters (and our reputation) if we introduce significant bugs a long way into a stable branches patch versions.  This will definitely make folk shy from upgrades even more.
>> > 
>> > IMO the 5.1 pilot seems such the much safer option, so I'm keen we can address our concerns with it to give those people their room to collaborate on it (and ofc appreciate the opposing concerns).  And added win from this, I can also see that it helps downstream forks incrementally rebase towards trunk more often– a huge win for helping find bugs in trunk earlier and to adopt trunk faster.  I see downstream forks struggle to keep up in an efficient manner, and that rebases onto year+ long new dev branches can be time-consumingly painful and hard to keep justifying as a ongoing business priority.  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.  That these folk are stepping forward to add their efforts in the community under such a pilot experiment is awesome, and IMHO a strong sign of a healthy growing community.
>> > 
>> > Mick
>> > 
>> > 
>> > > On 7 Oct 2025, at 03:52, Jeff Jirsa <jjirsa@gmail.com <ma...@gmail.com>> 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 <jmckenzie@apache.org <ma...@apache.org>> 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

[Josh McKenzie <jm...@apache.org>]

> 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).
> > 
> >  - More branches, more CI pain (Stefan):  yeah, this struck me as a legit concern.  We do now have pre-ci.cassandra.apache.org <http://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 upgrade process easier for users.)  
> > 
> >  - 5.1 needs to be maintained past 6.0 GA's date (Jeremiah, Isaac).  Continuing on from above.  Users need a window to upgrade from 5.1 to 6.0, so there has to be an overlap anyway.  But I can imagine, and maybe some downstream users involved here can answer this, that part of the value of this pilot is that specific dev features in trunk might be a lot harder to upgrade to than we realise– that it takes ~years to adjust fleets of production clusters to certain new features in the next major, while other features are just about back porting but provide value that's simply unjustifiable for a business to look past (and is what keeps C* being part of the tech stack in those companies).  A 5.1 branch might also serve purpose in providing specific features that help make the upgrade to the next major possible/feasible (like support for a blue-green upgrade solution), but this is purely speculative.
> > 
> >  - How other projects are doing it and their past discussions on what they decided (Ekaterina).  I agree with this– we should reference what they are doing and why (but also not presume that's how they would do it again today).  Do we know any folk active in any of those projects ? 
> > 
> > 
> > So FTR, based on the discussion so far, I'm really not keen of softening what goes into 5.0.x, finding having to work on bugs in our stable branches sometimes hard work, if not at times quite stressful, I really appreciate all efforts in maintaining their hardness.   I see the risk of production clusters (and our reputation) if we introduce significant bugs a long way into a stable branches patch versions.  This will definitely make folk shy from upgrades even more.
> > 
> > IMO the 5.1 pilot seems such the much safer option, so I'm keen we can address our concerns with it to give those people their room to collaborate on it (and ofc appreciate the opposing concerns).  And added win from this, I can also see that it helps downstream forks incrementally rebase towards trunk more often– a huge win for helping find bugs in trunk earlier and to adopt trunk faster.  I see downstream forks struggle to keep up in an efficient manner, and that rebases onto year+ long new dev branches can be time-consumingly painful and hard to keep justifying as a ongoing business priority.  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.  That these folk are stepping forward to add their efforts in the community under such a pilot experiment is awesome, and IMHO a strong sign of a healthy growing community.
> > 
> > Mick
> > 
> > 
> > > On 7 Oct 2025, at 03:52, Jeff Jirsa <jj...@gmail.com> 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 <jm...@apache.org> 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

[Marcus Eriksson <ma...@apache.org>]

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).
> 
>  - More branches, more CI pain (Stefan):  yeah, this struck me as a legit concern.  We do now have pre-ci.cassandra.apache.org <http://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 upgrade process easier for users.)  
> 
>  - 5.1 needs to be maintained past 6.0 GA's date (Jeremiah, Isaac).  Continuing on from above.  Users need a window to upgrade from 5.1 to 6.0, so there has to be an overlap anyway.  But I can imagine, and maybe some downstream users involved here can answer this, that part of the value of this pilot is that specific dev features in trunk might be a lot harder to upgrade to than we realise– that it takes ~years to adjust fleets of production clusters to certain new features in the next major, while other features are just about back porting but provide value that's simply unjustifiable for a business to look past (and is what keeps C* being part of the tech stack in those companies).  A 5.1 branch might also serve purpose in providing specific features that help make the upgrade to the next major possible/feasible (like support for a blue-green upgrade solution), but this is purely speculative.
> 
>  - How other projects are doing it and their past discussions on what they decided (Ekaterina).  I agree with this– we should reference what they are doing and why (but also not presume that's how they would do it again today).  Do we know any folk active in any of those projects ? 
> 
> 
> So FTR, based on the discussion so far, I'm really not keen of softening what goes into 5.0.x, finding having to work on bugs in our stable branches sometimes hard work, if not at times quite stressful, I really appreciate all efforts in maintaining their hardness.   I see the risk of production clusters (and our reputation) if we introduce significant bugs a long way into a stable branches patch versions.  This will definitely make folk shy from upgrades even more.
> 
> IMO the 5.1 pilot seems such the much safer option, so I'm keen we can address our concerns with it to give those people their room to collaborate on it (and ofc appreciate the opposing concerns).  And added win from this, I can also see that it helps downstream forks incrementally rebase towards trunk more often– a huge win for helping find bugs in trunk earlier and to adopt trunk faster.  I see downstream forks struggle to keep up in an efficient manner, and that rebases onto year+ long new dev branches can be time-consumingly painful and hard to keep justifying as a ongoing business priority.  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.  That these folk are stepping forward to add their efforts in the community under such a pilot experiment is awesome, and IMHO a strong sign of a healthy growing community.
> 
> Mick
> 
> 
> > On 7 Oct 2025, at 03:52, Jeff Jirsa <jj...@gmail.com> 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 <jm...@apache.org> 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

[Štefan Miklošovič <sm...@apache.org>]

I was keeping rewriting this email to not come across as arrogant or
misunderstood.

I see the value in the creation of 5.1 as Mick explained, but what I
was trying to do with having it in 5.0.x is just to have less work. As
a contributor who is with the codebase basically on a daily basis,
when something like this is presented to me, first of all I am seeing
"more work" on top of already enough work. The pool of committers is
not endless. Concrete people merge it and take care of that. So if we
want to introduce 5.1, sure, but please, the other part of the
equation here is that people who want to have 5.1 and contribute their
backports into that should step up their game, if they already have
not, and truly own it. I do not want 5.1 to be _just another branch I
need to take care of_ and I expect that concrete people (and / or
companies) will be owning it, otherwise what I perceive is that I will
be more busy.

That also touches releases (if they want to see 5.1 materialized in an
official release or not). Who is going to release it? You, Mick, with
Brandon? Because it sure won't be me if we (as my employer) do not
have an interest in doing so. So I would also expect that there will
be concrete people willing  to take care of that as well because last
time I checked there are basically three people doing releases so
asking to take care of releasing more is just ... nah.

So, sure, create 5.1, but there are also caveats attached to that so
that making it happen and taking care of that also means that the
substantial investment from people wanting to see it in the first
place is expected an it would be nice if we all realize what we are
buying ourselves into otherwise we would just make already busy people
more busier than before.


On Thu, Oct 9, 2025 at 12:30 AM Mick <mc...@apache.org> 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).
>
>  - More branches, more CI pain (Stefan):  yeah, this struck me as a legit concern.  We do now have pre-ci.cassandra.apache.org <http://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 upgrade process easier for users.)
>
>  - 5.1 needs to be maintained past 6.0 GA's date (Jeremiah, Isaac).  Continuing on from above.  Users need a window to upgrade from 5.1 to 6.0, so there has to be an overlap anyway.  But I can imagine, and maybe some downstream users involved here can answer this, that part of the value of this pilot is that specific dev features in trunk might be a lot harder to upgrade to than we realise– that it takes ~years to adjust fleets of production clusters to certain new features in the next major, while other features are just about back porting but provide value that's simply unjustifiable for a business to look past (and is what keeps C* being part of the tech stack in those companies).  A 5.1 branch might also serve purpose in providing specific features that help make the upgrade to the next major possible/feasible (like support for a blue-green upgrade solution), but this is purely speculative.
>
>  - How other projects are doing it and their past discussions on what they decided (Ekaterina).  I agree with this– we should reference what they are doing and why (but also not presume that's how they would do it again today).  Do we know any folk active in any of those projects ?
>
>
> So FTR, based on the discussion so far, I'm really not keen of softening what goes into 5.0.x, finding having to work on bugs in our stable branches sometimes hard work, if not at times quite stressful, I really appreciate all efforts in maintaining their hardness.   I see the risk of production clusters (and our reputation) if we introduce significant bugs a long way into a stable branches patch versions.  This will definitely make folk shy from upgrades even more.
>
> IMO the 5.1 pilot seems such the much safer option, so I'm keen we can address our concerns with it to give those people their room to collaborate on it (and ofc appreciate the opposing concerns).  And added win from this, I can also see that it helps downstream forks incrementally rebase towards trunk more often– a huge win for helping find bugs in trunk earlier and to adopt trunk faster.  I see downstream forks struggle to keep up in an efficient manner, and that rebases onto year+ long new dev branches can be time-consumingly painful and hard to keep justifying as a ongoing business priority.  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.  That these folk are stepping forward to add their efforts in the community under such a pilot experiment is awesome, and IMHO a strong sign of a healthy growing community.
>
> Mick
>
>
> > On 7 Oct 2025, at 03:52, Jeff Jirsa <jj...@gmail.com> 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 <jm...@apache.org> 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

[Mick <mc...@apache.org>]

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 <http://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 upgrade process easier for users.)  

 - 5.1 needs to be maintained past 6.0 GA's date (Jeremiah, Isaac).  Continuing on from above.  Users need a window to upgrade from 5.1 to 6.0, so there has to be an overlap anyway.  But I can imagine, and maybe some downstream users involved here can answer this, that part of the value of this pilot is that specific dev features in trunk might be a lot harder to upgrade to than we realise– that it takes ~years to adjust fleets of production clusters to certain new features in the next major, while other features are just about back porting but provide value that's simply unjustifiable for a business to look past (and is what keeps C* being part of the tech stack in those companies).  A 5.1 branch might also serve purpose in providing specific features that help make the upgrade to the next major possible/feasible (like support for a blue-green upgrade solution), but this is purely speculative.

 - How other projects are doing it and their past discussions on what they decided (Ekaterina).  I agree with this– we should reference what they are doing and why (but also not presume that's how they would do it again today).  Do we know any folk active in any of those projects ? 


So FTR, based on the discussion so far, I'm really not keen of softening what goes into 5.0.x, finding having to work on bugs in our stable branches sometimes hard work, if not at times quite stressful, I really appreciate all efforts in maintaining their hardness.   I see the risk of production clusters (and our reputation) if we introduce significant bugs a long way into a stable branches patch versions.  This will definitely make folk shy from upgrades even more.

IMO the 5.1 pilot seems such the much safer option, so I'm keen we can address our concerns with it to give those people their room to collaborate on it (and ofc appreciate the opposing concerns).  And added win from this, I can also see that it helps downstream forks incrementally rebase towards trunk more often– a huge win for helping find bugs in trunk earlier and to adopt trunk faster.  I see downstream forks struggle to keep up in an efficient manner, and that rebases onto year+ long new dev branches can be time-consumingly painful and hard to keep justifying as a ongoing business priority.  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.  That these folk are stepping forward to add their efforts in the community under such a pilot experiment is awesome, and IMHO a strong sign of a healthy growing community.

Mick


> On 7 Oct 2025, at 03:52, Jeff Jirsa <jj...@gmail.com> 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 <jm...@apache.org> 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

[Jeff Jirsa <jj...@gmail.com>]

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 <jm...@apache.org> 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

[Caleb Rackliffe <ca...@gmail.com>]

> 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 <ch...@gmail.com>
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č <sm...@apache.org>
> wrote:
>
>>
>>
>> On Wed, Oct 8, 2025 at 2:53 PM Josh McKenzie <jm...@apache.org>
>> 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 <dj...@apache.org> 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 <sa...@beobal.com> 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č <sm...@apache.org>
>>> 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 <jm...@apache.org>
>>> 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

[Jaydeep Chovatia <ch...@gmail.com>]

>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č <sm...@apache.org>
wrote:

>
>
> On Wed, Oct 8, 2025 at 2:53 PM Josh McKenzie <jm...@apache.org> 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 <dj...@apache.org> 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 <sa...@beobal.com> 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č <sm...@apache.org>
>> 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 <jm...@apache.org>
>> 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

[Štefan Miklošovič <sm...@apache.org>]

On Wed, Oct 8, 2025 at 2:53 PM Josh McKenzie <jm...@apache.org> 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 <dj...@apache.org> 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 <sa...@beobal.com> 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č <sm...@apache.org>
> 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 <jm...@apache.org>
> 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

[Josh McKenzie <jm...@apache.org>]

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 <dj...@apache.org> 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 <sa...@beobal.com> 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č <sm...@apache.org> 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 <jm...@apache.org> 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

[Štefan Miklošovič <sm...@apache.org>]

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 <dj...@apache.org> 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 <sa...@beobal.com> 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č <sm...@apache.org>
>> 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 <jm...@apache.org>
>> 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

[Sam Tunnicliffe <sa...@beobal.com>]

I feel you're conflating "ease" with "risk" here. Upgrades are not inherently difficult, despite the recent brouhaha about limiting some functionality while a major upgrade is in flight. Surely the problem is risk, operators are reluctant to take an upgrade until it has been vetted or battle tested and IMO this proposal only makes that more likely. 

> On 8 Oct 2025, at 08:45, Dinesh Joshi <dj...@apache.org> 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 <sa...@beobal.com> 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č <sm...@apache.org> 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 <jm...@apache.org> 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

[Dinesh Joshi <dj...@apache.org>]

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 <sa...@beobal.com> 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č <sm...@apache.org>
> 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 <jm...@apache.org>
> 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

[Sam Tunnicliffe <sa...@beobal.com>]

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č <sm...@apache.org> 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 <jm...@apache.org> 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

[Štefan Miklošovič <sm...@apache.org>]

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 <jm...@apache.org> 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

[Runtian Liu <cu...@gmail.com>]

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 <fr...@apache.org>
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

[Francisco Guerrero <fr...@apache.org>]

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