Re: [DISCUSS] Backport CEP-37 to all GA branches

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

Hi everybody,

I want to refresh this thread after the holidays. Is there an
agreement we reached? Is everybody on board with backporting to 4.1+?
How are we going to do this concretely? I guess Jaydeep would be
involved in the backporting as he just said. I honestly do not think
there is anybody else better suited to make it happen and your
willingness to do that is really appreciated.

Regards

On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
<ch...@gmail.com> wrote:
>
> FYI—regardless of the outcome, you can count on me to port CEP-37 in whatever form the community agrees on. As mentioned earlier, I’m already maintaining a private 4.1.6 fork (https://github.com/apache/cassandra/pull/3367).
> Thank you!
>
> Jaydeep
>
> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com> wrote:
>>
>> I'm really interested in this thread, but don't see an update on where we landed in terms of backporting and also the amount of work involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026 work and where this discussion goes will really help me optimally plan, which is why I'm asking.
>> Thanks!
>>
>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <e....@gmail.com> wrote:
>>>
>>> Seems like the 4.1 branch would still require some work to cover everything raised on this thread? Have anyone evaluated how much work that can be?
>>>
>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then probably we better have it only in 5.0?
>>>
>>> Do people think it makes sense to create some kind of user survey around this work, too? Posted in @user
>>>
>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org> wrote:
>>>>
>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and backporting to both would increase the risk and maintenance burden.
>>>>
>>>> It would but by how much?
>>>>
>>>> 2 things jump out to me re: risk and maintenance:
>>>>
>>>> Risk: We kind of need to tackle the "version straddle w/schema table diffs is currently Bad and makes rollbacks manual and brittle" broadly; this feature is just one more example of that though it's a little exacerbated by discussing doing something like this in a patch release. The ergonomics of the "one-way-door without a human manually deleting columns" part holds true cross-MAJOR too. "Progress" here seems like it's either we handle this on a case-by-case basis w/flags to remove those schema entries on rollback (kinda ew), or more durably with an elegant solution in the long term, i.e. capabilities framework, though that doesn't answer the "we explode when schemas don't match" bit.
>>>>
>>>> Maintenance: maintaining this across 4 branches is clearly more toil than across 2.
>>>>
>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd like all of us to be able to more freely consider making changes to schema tables w/out the complexity burden we have right now and the operator toil and risk that comes along with it.
>>>>
>>>> The maintenance toil bit - I have less opinions on. Kind of depends on how many people are on 4.0/4.1 right now that we'd expect to be on 4.1 for another year until 7.0 hits and whether we think they'd benefit from the feature (and contribute to bettering it) during that year I guess.
>>>>
>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>
>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and backporting to both would increase the risk and maintenance burden.
>>>>
>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

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

There is a voting thread for 5.0.8 this backport is in, and was staged
basically just because of that. Voting on that would be appreciated so
users can indeed start to benefit from this highly anticipated feature
in 5.0 too.

On Wed, Apr 8, 2026 at 10:52 PM Jaydeep Chovatia
<ch...@gmail.com> wrote:
>
> Awesome to see the feature available in 5.0 now. Thanks a lot, Paulo, for doing the heavy lifting!
>
> Jayeep
>
>
>
> On Wed, Apr 8, 2026 at 9:34 AM Isaac Reath <is...@gmail.com> wrote:
>>
>> This is awesome! Big thank you and congrats to everyone who worked to make this happen!
>>
>> On Wed, Apr 8, 2026 at 12:07 PM Paulo Motta <pa...@apache.org> wrote:
>>>
>>> I'd like to announce that the backport of AutoRepair has been committed to cassandra-5.0[1]. Thanks Andy and Jaydeep for the thorough review!
>>>
>>> This feature is gated by a JVM property "cassandra.autorepair.enable", see NEWS.txt for more information on enabling this feature[2]. System schema changes required to support this feature are only performed when the flag is enabled. As a consequence of that, it is not possible to disable the flag once enabled. This is a trade-off required to prevent schema changes during a minor upgrade for users who do not intend to enable the feature.
>>>
>>> [1] - https://github.com/apache/cassandra/commit/9500eb129bd61b2eaec78df3b9a7a5ebfca91c92
>>> [2] - https://github.com/apache/cassandra/blob/cassandra-5.0/NEWS.txt#L79
>>>
>>> On Fri, Mar 6, 2026 at 4:03 PM Paulo Motta <pa...@apache.org> wrote:
>>>>
>>>> Thanks Jaydeep and Andy for the review! I have addressed the review comments and this should be ready for another look.
>>>>
>>>> I wanted to give a heads up to the community that we should be merging this 5.0 backport soon in case there are any outstanding concerns.
>>>>
>>>> On Sun, Feb 22, 2026 at 12:59 AM Tolbert, Andy <x...@andrewtolbert.com> wrote:
>>>>>
>>>>> I finally got around to playing around with Paulo's 5.0 backport branch as well and added some review feedback.  I agree with Jaydeep that it looks great, nice work Paulo!
>>>>>
>>>>> The write up on the PR in NEWS.txt (https://github.com/apache/cassandra/pull/4558/changes#diff-95c20d744db732cdbca24c3e0406c10005ecf7fe8b5719c2fdf2b8af3fcedc79) does a great job describing how to opt into the feature and how it mitigates any risk.  I'm hopeful that the approach taken here makes a giving a +1 to a possible backport vote an easier choice for folks!
>>>>>
>>>>> Thanks!
>>>>> Andy
>>>>>
>>>>> On Sun, Feb 8, 2026 at 8:03 PM Jaydeep Chovatia <ch...@gmail.com> wrote:
>>>>>>
>>>>>> I have looked at the PR. Overall, it looks great. Added a few comments.
>>>>>>
>>>>>> Jaydeep
>>>>>>
>>>>>> On Fri, Jan 30, 2026 at 8:20 PM Jaydeep Chovatia <ch...@gmail.com> wrote:
>>>>>>>
>>>>>>> I will take a look at it. Happy to see AutoRepair in 5.0.
>>>>>>> Thank you for the patch, Paulo!
>>>>>>>
>>>>>>> Jaydeep
>>>>>>>
>>>>>>> On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <x...@andrewtolbert.com> wrote:
>>>>>>>>
>>>>>>>> I'd be happy to take a look at reviewing this as well as I would be excited to see Auto Repair in 5.0.  Thank you for the patch, Paulo!
>>>>>>>>
>>>>>>>> Andy
>>>>>>>>
>>>>>>>> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> I have submitted a patch porting AutoRepair to 5.0 on CASSANDRA-21138[1] and tagged Jaydeep Chovatia for review. I would greatly appreciate other sets of eyes, especially those involved with the original CEP-37 effort.
>>>>>>>>>
>>>>>>>>> The feature is disabled by default and no schema changes are made unless a JVM flag is enabled to reduce upgrade risk to users who do not intend to enable this feature.
>>>>>>>>>
>>>>>>>>> Please let us know if you have any questions or concerns about having this merged in 5.0.
>>>>>>>>>
>>>>>>>>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>>>>>>>>>
>>>>>>>>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <ch...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Sure, I am happy to review it whenever it's ready, Paulo. Please let me know.
>>>>>>>>>>
>>>>>>>>>> Jaydeep
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I agree with Scott. I don't think we should backport this to 4.1 due to the compatibility issues raised plus this branch has already been stabilized for a while.
>>>>>>>>>>>
>>>>>>>>>>> I think backporting auto-repair to 5.0 would be more appropriate as it would encourage users to adopt this version and get closer to trunk, rather than encouraging users to stick to an older version.
>>>>>>>>>>>
>>>>>>>>>>> I decided to take a stab at backporting auto-repair + additional fixes to 5.0 on this preliminary PR: https://github.com/apache/cassandra/pull/4558
>>>>>>>>>>>
>>>>>>>>>>> It's not ready for review yet since I need to gate the schema changes under a feature flag, but I think I can get it ready by the end of week.
>>>>>>>>>>>
>>>>>>>>>>> If there's no opposition against shipping this in 5.0 maybe I can create a JIRA and have Jaydeep review it ?
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <sc...@paradoxica.net> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> For the purpose of a quick straw poll, I’m not opposed to backporting to 5.x, but I don’t support backporting to 4.x-series releases for the compatibility and upgrade complexity reasons previously discussed.
>>>>>>>>>>>>
>>>>>>>>>>>> - Scott
>>>>>>>>>>>>
>>>>>>>>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <sm...@apache.org> wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> > Hi everybody,
>>>>>>>>>>>> >
>>>>>>>>>>>> > I want to refresh this thread after the holidays. Is there an
>>>>>>>>>>>> > agreement we reached? Is everybody on board with backporting to 4.1+?
>>>>>>>>>>>> > How are we going to do this concretely? I guess Jaydeep would be
>>>>>>>>>>>> > involved in the backporting as he just said. I honestly do not think
>>>>>>>>>>>> > there is anybody else better suited to make it happen and your
>>>>>>>>>>>> > willingness to do that is really appreciated.
>>>>>>>>>>>> >
>>>>>>>>>>>> > Regards
>>>>>>>>>>>> >
>>>>>>>>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>>>>>>>>>> >> <ch...@gmail.com> wrote:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> FYI—regardless of the outcome, you can count on me to port CEP-37 in whatever form the community agrees on. As mentioned earlier, I’m already maintaining a private 4.1.6 fork (https://github.com/apache/cassandra/pull/3367).
>>>>>>>>>>>> >> Thank you!
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> Jaydeep
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com> wrote:
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> I'm really interested in this thread, but don't see an update on where we landed in terms of backporting and also the amount of work involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026 work and where this discussion goes will really help me optimally plan, which is why I'm asking.
>>>>>>>>>>>> >>> Thanks!
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <e....@gmail.com> wrote:
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> Seems like the 4.1 branch would still require some work to cover everything raised on this thread? Have anyone evaluated how much work that can be?
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then probably we better have it only in 5.0?
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> Do people think it makes sense to create some kind of user survey around this work, too? Posted in @user
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org> wrote:
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and backporting to both would increase the risk and maintenance burden.
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> It would but by how much?
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> Risk: We kind of need to tackle the "version straddle w/schema table diffs is currently Bad and makes rollbacks manual and brittle" broadly; this feature is just one more example of that though it's a little exacerbated by discussing doing something like this in a patch release. The ergonomics of the "one-way-door without a human manually deleting columns" part holds true cross-MAJOR too. "Progress" here seems like it's either we handle this on a case-by-case basis w/flags to remove those schema entries on rollback (kinda ew), or more durably with an elegant solution in the long term, i.e. capabilities framework, though that doesn't answer the "we explode when schemas don't match" bit.
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly more toil than across 2.
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd like all of us to be able to more freely consider making changes to schema tables w/out the complexity burden we have right now and the operator toil and risk that comes along with it.
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of depends on how many people are on 4.0/4.1 right now that we'd expect to be on 4.1 for another year until 7.0 hits and whether we think they'd benefit from the feature (and contribute to bettering it) during that year I guess.
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and backporting to both would increase the risk and maintenance burden.
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

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

Awesome to see the feature available in 5.0 now. Thanks a lot, Paulo, for
doing the heavy lifting!

Jayeep



On Wed, Apr 8, 2026 at 9:34 AM Isaac Reath <is...@gmail.com> wrote:

> This is awesome! Big thank you and congrats to everyone who worked to make
> this happen!
>
> On Wed, Apr 8, 2026 at 12:07 PM Paulo Motta <pa...@apache.org> wrote:
>
>> I'd like to announce that the backport of AutoRepair has been committed
>> to cassandra-5.0[1]. Thanks Andy and Jaydeep for the thorough review!
>>
>> This feature is gated by a JVM property "cassandra.autorepair.enable",
>> see NEWS.txt for more information on enabling this feature[2]. System
>> schema changes required to support this feature are only performed when the
>> flag is enabled. As a consequence of that, it is not possible to disable
>> the flag once enabled. This is a trade-off required to prevent schema
>> changes during a minor upgrade for users who do not intend to enable the
>> feature.
>>
>> [1] -
>> https://github.com/apache/cassandra/commit/9500eb129bd61b2eaec78df3b9a7a5ebfca91c92
>> [2] - https://github.com/apache/cassandra/blob/cassandra-5.0/NEWS.txt#L79
>>
>> On Fri, Mar 6, 2026 at 4:03 PM Paulo Motta <pa...@apache.org> wrote:
>>
>>> Thanks Jaydeep and Andy for the review! I have addressed the review
>>> comments and this should be ready for another look.
>>>
>>> I wanted to give a heads up to the community that we should be merging
>>> this 5.0 backport soon in case there are any outstanding concerns.
>>>
>>> On Sun, Feb 22, 2026 at 12:59 AM Tolbert, Andy <x...@andrewtolbert.com>
>>> wrote:
>>>
>>>> I finally got around to playing around with Paulo's 5.0 backport branch
>>>> as well and added some review feedback.  I agree with Jaydeep that it looks
>>>> great, nice work Paulo!
>>>>
>>>> The write up on the PR in NEWS.txt (
>>>> https://github.com/apache/cassandra/pull/4558/changes#diff-95c20d744db732cdbca24c3e0406c10005ecf7fe8b5719c2fdf2b8af3fcedc79)
>>>> does a great job describing how to opt into the feature and how it
>>>> mitigates any risk.  I'm hopeful that the approach taken here makes a
>>>> giving a +1 to a possible backport vote an easier choice for folks!
>>>>
>>>> Thanks!
>>>> Andy
>>>>
>>>> On Sun, Feb 8, 2026 at 8:03 PM Jaydeep Chovatia <
>>>> chovatia.jaydeep@gmail.com> wrote:
>>>>
>>>>> I have looked at the PR. Overall, it looks great. Added a few comments.
>>>>>
>>>>> Jaydeep
>>>>>
>>>>> On Fri, Jan 30, 2026 at 8:20 PM Jaydeep Chovatia <
>>>>> chovatia.jaydeep@gmail.com> wrote:
>>>>>
>>>>>> I will take a look at it. Happy to see AutoRepair in 5.0.
>>>>>> Thank you for the patch, Paulo!
>>>>>>
>>>>>> Jaydeep
>>>>>>
>>>>>> On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <x...@andrewtolbert.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'd be happy to take a look at reviewing this as well as I would be
>>>>>>> excited to see Auto Repair in 5.0.  Thank you for the patch, Paulo!
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I have submitted a patch porting AutoRepair to 5.0 on
>>>>>>>> CASSANDRA-21138[1] and tagged Jaydeep Chovatia for review. I would greatly
>>>>>>>> appreciate other sets of eyes, especially those involved with the original
>>>>>>>> CEP-37 effort.
>>>>>>>>
>>>>>>>> The feature is disabled by default and no schema changes are made
>>>>>>>> unless a JVM flag is enabled to reduce upgrade risk to users who do not
>>>>>>>> intend to enable this feature.
>>>>>>>>
>>>>>>>> Please let us know if you have any questions or concerns about
>>>>>>>> having this merged in 5.0.
>>>>>>>>
>>>>>>>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>>>>>>>>
>>>>>>>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <
>>>>>>>> chovatia.jaydeep@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Sure, I am happy to review it whenever it's ready, Paulo. Please
>>>>>>>>> let me know.
>>>>>>>>>
>>>>>>>>> Jaydeep
>>>>>>>>>
>>>>>>>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I agree with Scott. I don't think we should backport this to 4.1
>>>>>>>>>> due to the compatibility issues raised plus this branch has already been
>>>>>>>>>> stabilized for a while.
>>>>>>>>>>
>>>>>>>>>> I think backporting auto-repair to 5.0 would be more appropriate
>>>>>>>>>> as it would encourage users to adopt this version and get closer to trunk,
>>>>>>>>>> rather than encouraging users to stick to an older version.
>>>>>>>>>>
>>>>>>>>>> I decided to take a stab at backporting auto-repair +
>>>>>>>>>> additional fixes to 5.0 on this preliminary PR:
>>>>>>>>>> https://github.com/apache/cassandra/pull/4558
>>>>>>>>>>
>>>>>>>>>> It's not ready for review yet since I need to gate the schema
>>>>>>>>>> changes under a feature flag, but I think I can get it ready by the end of
>>>>>>>>>> week.
>>>>>>>>>>
>>>>>>>>>> If there's no opposition against shipping this in 5.0 maybe I can
>>>>>>>>>> create a JIRA and have Jaydeep review it ?
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <
>>>>>>>>>> scott@paradoxica.net> wrote:
>>>>>>>>>>
>>>>>>>>>>> For the purpose of a quick straw poll, I’m not opposed to
>>>>>>>>>>> backporting to 5.x, but I don’t support backporting to 4.x-series releases
>>>>>>>>>>> for the compatibility and upgrade complexity reasons previously discussed.
>>>>>>>>>>>
>>>>>>>>>>> - Scott
>>>>>>>>>>>
>>>>>>>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <
>>>>>>>>>>> smiklosovic@apache.org> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > Hi everybody,
>>>>>>>>>>> >
>>>>>>>>>>> > I want to refresh this thread after the holidays. Is there an
>>>>>>>>>>> > agreement we reached? Is everybody on board with backporting
>>>>>>>>>>> to 4.1+?
>>>>>>>>>>> > How are we going to do this concretely? I guess Jaydeep would
>>>>>>>>>>> be
>>>>>>>>>>> > involved in the backporting as he just said. I honestly do not
>>>>>>>>>>> think
>>>>>>>>>>> > there is anybody else better suited to make it happen and your
>>>>>>>>>>> > willingness to do that is really appreciated.
>>>>>>>>>>> >
>>>>>>>>>>> > Regards
>>>>>>>>>>> >
>>>>>>>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>>>>>>>>> >> <ch...@gmail.com> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> FYI—regardless of the outcome, you can count on me to port
>>>>>>>>>>> CEP-37 in whatever form the community agrees on. As mentioned earlier, I’m
>>>>>>>>>>> already maintaining a private 4.1.6 fork (
>>>>>>>>>>> https://github.com/apache/cassandra/pull/3367).
>>>>>>>>>>> >> Thank you!
>>>>>>>>>>> >>
>>>>>>>>>>> >> Jaydeep
>>>>>>>>>>> >>
>>>>>>>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <
>>>>>>>>>>> mgreen32@gmail.com> wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> I'm really interested in this thread, but don't see an
>>>>>>>>>>> update on where we landed in terms of backporting and also the amount of
>>>>>>>>>>> work involved.  I'm all for backporting to 5.x minimally!  I'm planning our
>>>>>>>>>>> 2026 work and where this discussion goes will really help me optimally
>>>>>>>>>>> plan, which is why I'm asking.
>>>>>>>>>>> >>> Thanks!
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>>>>>>>>>> e.dimitrova@gmail.com> wrote:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Seems like the 4.1 branch would still require some work to
>>>>>>>>>>> cover everything raised on this thread? Have anyone evaluated how much work
>>>>>>>>>>> that can be?
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then
>>>>>>>>>>> probably we better have it only in 5.0?
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Do people think it makes sense to create some kind of user
>>>>>>>>>>> survey around this work, too? Posted in @user
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <
>>>>>>>>>>> jmckenzie@apache.org> wrote:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0,
>>>>>>>>>>> and backporting to both would increase the risk and maintenance burden.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> It would but by how much?
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Risk: We kind of need to tackle the "version straddle
>>>>>>>>>>> w/schema table diffs is currently Bad and makes rollbacks manual and
>>>>>>>>>>> brittle" broadly; this feature is just one more example of that though it's
>>>>>>>>>>> a little exacerbated by discussing doing something like this in a patch
>>>>>>>>>>> release. The ergonomics of the "one-way-door without a human manually
>>>>>>>>>>> deleting columns" part holds true cross-MAJOR too. "Progress" here seems
>>>>>>>>>>> like it's either we handle this on a case-by-case basis w/flags to remove
>>>>>>>>>>> those schema entries on rollback (kinda ew), or more durably with an
>>>>>>>>>>> elegant solution in the long term, i.e. capabilities framework, though that
>>>>>>>>>>> doesn't answer the "we explode when schemas don't match" bit.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly
>>>>>>>>>>> more toil than across 2.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk
>>>>>>>>>>> bit; I'd like all of us to be able to more freely consider making changes
>>>>>>>>>>> to schema tables w/out the complexity burden we have right now and the
>>>>>>>>>>> operator toil and risk that comes along with it.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind
>>>>>>>>>>> of depends on how many people are on 4.0/4.1 right now that we'd expect to
>>>>>>>>>>> be on 4.1 for another year until 7.0 hits and whether we think they'd
>>>>>>>>>>> benefit from the feature (and contribute to bettering it) during that year
>>>>>>>>>>> I guess.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0,
>>>>>>>>>>> and backporting to both would increase the risk and maintenance burden.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>>
>>>>>>>>>>>
>>>>>>>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

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

This is awesome! Big thank you and congrats to everyone who worked to make
this happen!

On Wed, Apr 8, 2026 at 12:07 PM Paulo Motta <pa...@apache.org> wrote:

> I'd like to announce that the backport of AutoRepair has been committed to
> cassandra-5.0[1]. Thanks Andy and Jaydeep for the thorough review!
>
> This feature is gated by a JVM property "cassandra.autorepair.enable", see
> NEWS.txt for more information on enabling this feature[2]. System schema
> changes required to support this feature are only performed when the flag
> is enabled. As a consequence of that, it is not possible to disable the
> flag once enabled. This is a trade-off required to prevent schema changes
> during a minor upgrade for users who do not intend to enable the feature.
>
> [1] -
> https://github.com/apache/cassandra/commit/9500eb129bd61b2eaec78df3b9a7a5ebfca91c92
> [2] - https://github.com/apache/cassandra/blob/cassandra-5.0/NEWS.txt#L79
>
> On Fri, Mar 6, 2026 at 4:03 PM Paulo Motta <pa...@apache.org> wrote:
>
>> Thanks Jaydeep and Andy for the review! I have addressed the review
>> comments and this should be ready for another look.
>>
>> I wanted to give a heads up to the community that we should be merging
>> this 5.0 backport soon in case there are any outstanding concerns.
>>
>> On Sun, Feb 22, 2026 at 12:59 AM Tolbert, Andy <x...@andrewtolbert.com>
>> wrote:
>>
>>> I finally got around to playing around with Paulo's 5.0 backport branch
>>> as well and added some review feedback.  I agree with Jaydeep that it looks
>>> great, nice work Paulo!
>>>
>>> The write up on the PR in NEWS.txt (
>>> https://github.com/apache/cassandra/pull/4558/changes#diff-95c20d744db732cdbca24c3e0406c10005ecf7fe8b5719c2fdf2b8af3fcedc79)
>>> does a great job describing how to opt into the feature and how it
>>> mitigates any risk.  I'm hopeful that the approach taken here makes a
>>> giving a +1 to a possible backport vote an easier choice for folks!
>>>
>>> Thanks!
>>> Andy
>>>
>>> On Sun, Feb 8, 2026 at 8:03 PM Jaydeep Chovatia <
>>> chovatia.jaydeep@gmail.com> wrote:
>>>
>>>> I have looked at the PR. Overall, it looks great. Added a few comments.
>>>>
>>>> Jaydeep
>>>>
>>>> On Fri, Jan 30, 2026 at 8:20 PM Jaydeep Chovatia <
>>>> chovatia.jaydeep@gmail.com> wrote:
>>>>
>>>>> I will take a look at it. Happy to see AutoRepair in 5.0.
>>>>> Thank you for the patch, Paulo!
>>>>>
>>>>> Jaydeep
>>>>>
>>>>> On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <x...@andrewtolbert.com>
>>>>> wrote:
>>>>>
>>>>>> I'd be happy to take a look at reviewing this as well as I would be
>>>>>> excited to see Auto Repair in 5.0.  Thank you for the patch, Paulo!
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org> wrote:
>>>>>>
>>>>>>> I have submitted a patch porting AutoRepair to 5.0 on
>>>>>>> CASSANDRA-21138[1] and tagged Jaydeep Chovatia for review. I would greatly
>>>>>>> appreciate other sets of eyes, especially those involved with the original
>>>>>>> CEP-37 effort.
>>>>>>>
>>>>>>> The feature is disabled by default and no schema changes are made
>>>>>>> unless a JVM flag is enabled to reduce upgrade risk to users who do not
>>>>>>> intend to enable this feature.
>>>>>>>
>>>>>>> Please let us know if you have any questions or concerns about
>>>>>>> having this merged in 5.0.
>>>>>>>
>>>>>>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>>>>>>>
>>>>>>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <
>>>>>>> chovatia.jaydeep@gmail.com> wrote:
>>>>>>>
>>>>>>>> Sure, I am happy to review it whenever it's ready, Paulo. Please
>>>>>>>> let me know.
>>>>>>>>
>>>>>>>> Jaydeep
>>>>>>>>
>>>>>>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I agree with Scott. I don't think we should backport this to 4.1
>>>>>>>>> due to the compatibility issues raised plus this branch has already been
>>>>>>>>> stabilized for a while.
>>>>>>>>>
>>>>>>>>> I think backporting auto-repair to 5.0 would be more appropriate
>>>>>>>>> as it would encourage users to adopt this version and get closer to trunk,
>>>>>>>>> rather than encouraging users to stick to an older version.
>>>>>>>>>
>>>>>>>>> I decided to take a stab at backporting auto-repair +
>>>>>>>>> additional fixes to 5.0 on this preliminary PR:
>>>>>>>>> https://github.com/apache/cassandra/pull/4558
>>>>>>>>>
>>>>>>>>> It's not ready for review yet since I need to gate the schema
>>>>>>>>> changes under a feature flag, but I think I can get it ready by the end of
>>>>>>>>> week.
>>>>>>>>>
>>>>>>>>> If there's no opposition against shipping this in 5.0 maybe I can
>>>>>>>>> create a JIRA and have Jaydeep review it ?
>>>>>>>>>
>>>>>>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <
>>>>>>>>> scott@paradoxica.net> wrote:
>>>>>>>>>
>>>>>>>>>> For the purpose of a quick straw poll, I’m not opposed to
>>>>>>>>>> backporting to 5.x, but I don’t support backporting to 4.x-series releases
>>>>>>>>>> for the compatibility and upgrade complexity reasons previously discussed.
>>>>>>>>>>
>>>>>>>>>> - Scott
>>>>>>>>>>
>>>>>>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <
>>>>>>>>>> smiklosovic@apache.org> wrote:
>>>>>>>>>> >
>>>>>>>>>> > Hi everybody,
>>>>>>>>>> >
>>>>>>>>>> > I want to refresh this thread after the holidays. Is there an
>>>>>>>>>> > agreement we reached? Is everybody on board with backporting to
>>>>>>>>>> 4.1+?
>>>>>>>>>> > How are we going to do this concretely? I guess Jaydeep would be
>>>>>>>>>> > involved in the backporting as he just said. I honestly do not
>>>>>>>>>> think
>>>>>>>>>> > there is anybody else better suited to make it happen and your
>>>>>>>>>> > willingness to do that is really appreciated.
>>>>>>>>>> >
>>>>>>>>>> > Regards
>>>>>>>>>> >
>>>>>>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>>>>>>>> >> <ch...@gmail.com> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> FYI—regardless of the outcome, you can count on me to port
>>>>>>>>>> CEP-37 in whatever form the community agrees on. As mentioned earlier, I’m
>>>>>>>>>> already maintaining a private 4.1.6 fork (
>>>>>>>>>> https://github.com/apache/cassandra/pull/3367).
>>>>>>>>>> >> Thank you!
>>>>>>>>>> >>
>>>>>>>>>> >> Jaydeep
>>>>>>>>>> >>
>>>>>>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <
>>>>>>>>>> mgreen32@gmail.com> wrote:
>>>>>>>>>> >>>
>>>>>>>>>> >>> I'm really interested in this thread, but don't see an update
>>>>>>>>>> on where we landed in terms of backporting and also the amount of work
>>>>>>>>>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>>>>>>>>>> work and where this discussion goes will really help me optimally plan,
>>>>>>>>>> which is why I'm asking.
>>>>>>>>>> >>> Thanks!
>>>>>>>>>> >>>
>>>>>>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>>>>>>>>> e.dimitrova@gmail.com> wrote:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Seems like the 4.1 branch would still require some work to
>>>>>>>>>> cover everything raised on this thread? Have anyone evaluated how much work
>>>>>>>>>> that can be?
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then
>>>>>>>>>> probably we better have it only in 5.0?
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Do people think it makes sense to create some kind of user
>>>>>>>>>> survey around this work, too? Posted in @user
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <
>>>>>>>>>> jmckenzie@apache.org> wrote:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0,
>>>>>>>>>> and backporting to both would increase the risk and maintenance burden.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> It would but by how much?
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Risk: We kind of need to tackle the "version straddle
>>>>>>>>>> w/schema table diffs is currently Bad and makes rollbacks manual and
>>>>>>>>>> brittle" broadly; this feature is just one more example of that though it's
>>>>>>>>>> a little exacerbated by discussing doing something like this in a patch
>>>>>>>>>> release. The ergonomics of the "one-way-door without a human manually
>>>>>>>>>> deleting columns" part holds true cross-MAJOR too. "Progress" here seems
>>>>>>>>>> like it's either we handle this on a case-by-case basis w/flags to remove
>>>>>>>>>> those schema entries on rollback (kinda ew), or more durably with an
>>>>>>>>>> elegant solution in the long term, i.e. capabilities framework, though that
>>>>>>>>>> doesn't answer the "we explode when schemas don't match" bit.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly
>>>>>>>>>> more toil than across 2.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit;
>>>>>>>>>> I'd like all of us to be able to more freely consider making changes to
>>>>>>>>>> schema tables w/out the complexity burden we have right now and the
>>>>>>>>>> operator toil and risk that comes along with it.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of
>>>>>>>>>> depends on how many people are on 4.0/4.1 right now that we'd expect to be
>>>>>>>>>> on 4.1 for another year until 7.0 hits and whether we think they'd benefit
>>>>>>>>>> from the feature (and contribute to bettering it) during that year I guess.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0,
>>>>>>>>>> and backporting to both would increase the risk and maintenance burden.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>>
>>>>>>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

[Paulo Motta <pa...@apache.org>]

I'd like to announce that the backport of AutoRepair has been committed to
cassandra-5.0[1]. Thanks Andy and Jaydeep for the thorough review!

This feature is gated by a JVM property "cassandra.autorepair.enable", see
NEWS.txt for more information on enabling this feature[2]. System schema
changes required to support this feature are only performed when the flag
is enabled. As a consequence of that, it is not possible to disable the
flag once enabled. This is a trade-off required to prevent schema changes
during a minor upgrade for users who do not intend to enable the feature.

[1] -
https://github.com/apache/cassandra/commit/9500eb129bd61b2eaec78df3b9a7a5ebfca91c92
[2] - https://github.com/apache/cassandra/blob/cassandra-5.0/NEWS.txt#L79

On Fri, Mar 6, 2026 at 4:03 PM Paulo Motta <pa...@apache.org> wrote:

> Thanks Jaydeep and Andy for the review! I have addressed the review
> comments and this should be ready for another look.
>
> I wanted to give a heads up to the community that we should be merging
> this 5.0 backport soon in case there are any outstanding concerns.
>
> On Sun, Feb 22, 2026 at 12:59 AM Tolbert, Andy <x...@andrewtolbert.com>
> wrote:
>
>> I finally got around to playing around with Paulo's 5.0 backport branch
>> as well and added some review feedback.  I agree with Jaydeep that it looks
>> great, nice work Paulo!
>>
>> The write up on the PR in NEWS.txt (
>> https://github.com/apache/cassandra/pull/4558/changes#diff-95c20d744db732cdbca24c3e0406c10005ecf7fe8b5719c2fdf2b8af3fcedc79)
>> does a great job describing how to opt into the feature and how it
>> mitigates any risk.  I'm hopeful that the approach taken here makes a
>> giving a +1 to a possible backport vote an easier choice for folks!
>>
>> Thanks!
>> Andy
>>
>> On Sun, Feb 8, 2026 at 8:03 PM Jaydeep Chovatia <
>> chovatia.jaydeep@gmail.com> wrote:
>>
>>> I have looked at the PR. Overall, it looks great. Added a few comments.
>>>
>>> Jaydeep
>>>
>>> On Fri, Jan 30, 2026 at 8:20 PM Jaydeep Chovatia <
>>> chovatia.jaydeep@gmail.com> wrote:
>>>
>>>> I will take a look at it. Happy to see AutoRepair in 5.0.
>>>> Thank you for the patch, Paulo!
>>>>
>>>> Jaydeep
>>>>
>>>> On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <x...@andrewtolbert.com>
>>>> wrote:
>>>>
>>>>> I'd be happy to take a look at reviewing this as well as I would be
>>>>> excited to see Auto Repair in 5.0.  Thank you for the patch, Paulo!
>>>>>
>>>>> Andy
>>>>>
>>>>> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org> wrote:
>>>>>
>>>>>> I have submitted a patch porting AutoRepair to 5.0 on
>>>>>> CASSANDRA-21138[1] and tagged Jaydeep Chovatia for review. I would greatly
>>>>>> appreciate other sets of eyes, especially those involved with the original
>>>>>> CEP-37 effort.
>>>>>>
>>>>>> The feature is disabled by default and no schema changes are made
>>>>>> unless a JVM flag is enabled to reduce upgrade risk to users who do not
>>>>>> intend to enable this feature.
>>>>>>
>>>>>> Please let us know if you have any questions or concerns about having
>>>>>> this merged in 5.0.
>>>>>>
>>>>>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>>>>>>
>>>>>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <
>>>>>> chovatia.jaydeep@gmail.com> wrote:
>>>>>>
>>>>>>> Sure, I am happy to review it whenever it's ready, Paulo. Please let
>>>>>>> me know.
>>>>>>>
>>>>>>> Jaydeep
>>>>>>>
>>>>>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I agree with Scott. I don't think we should backport this to 4.1
>>>>>>>> due to the compatibility issues raised plus this branch has already been
>>>>>>>> stabilized for a while.
>>>>>>>>
>>>>>>>> I think backporting auto-repair to 5.0 would be more appropriate as
>>>>>>>> it would encourage users to adopt this version and get closer to trunk,
>>>>>>>> rather than encouraging users to stick to an older version.
>>>>>>>>
>>>>>>>> I decided to take a stab at backporting auto-repair +
>>>>>>>> additional fixes to 5.0 on this preliminary PR:
>>>>>>>> https://github.com/apache/cassandra/pull/4558
>>>>>>>>
>>>>>>>> It's not ready for review yet since I need to gate the schema
>>>>>>>> changes under a feature flag, but I think I can get it ready by the end of
>>>>>>>> week.
>>>>>>>>
>>>>>>>> If there's no opposition against shipping this in 5.0 maybe I can
>>>>>>>> create a JIRA and have Jaydeep review it ?
>>>>>>>>
>>>>>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <
>>>>>>>> scott@paradoxica.net> wrote:
>>>>>>>>
>>>>>>>>> For the purpose of a quick straw poll, I’m not opposed to
>>>>>>>>> backporting to 5.x, but I don’t support backporting to 4.x-series releases
>>>>>>>>> for the compatibility and upgrade complexity reasons previously discussed.
>>>>>>>>>
>>>>>>>>> - Scott
>>>>>>>>>
>>>>>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <
>>>>>>>>> smiklosovic@apache.org> wrote:
>>>>>>>>> >
>>>>>>>>> > Hi everybody,
>>>>>>>>> >
>>>>>>>>> > I want to refresh this thread after the holidays. Is there an
>>>>>>>>> > agreement we reached? Is everybody on board with backporting to
>>>>>>>>> 4.1+?
>>>>>>>>> > How are we going to do this concretely? I guess Jaydeep would be
>>>>>>>>> > involved in the backporting as he just said. I honestly do not
>>>>>>>>> think
>>>>>>>>> > there is anybody else better suited to make it happen and your
>>>>>>>>> > willingness to do that is really appreciated.
>>>>>>>>> >
>>>>>>>>> > Regards
>>>>>>>>> >
>>>>>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>>>>>>> >> <ch...@gmail.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >> FYI—regardless of the outcome, you can count on me to port
>>>>>>>>> CEP-37 in whatever form the community agrees on. As mentioned earlier, I’m
>>>>>>>>> already maintaining a private 4.1.6 fork (
>>>>>>>>> https://github.com/apache/cassandra/pull/3367).
>>>>>>>>> >> Thank you!
>>>>>>>>> >>
>>>>>>>>> >> Jaydeep
>>>>>>>>> >>
>>>>>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <
>>>>>>>>> mgreen32@gmail.com> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> I'm really interested in this thread, but don't see an update
>>>>>>>>> on where we landed in terms of backporting and also the amount of work
>>>>>>>>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>>>>>>>>> work and where this discussion goes will really help me optimally plan,
>>>>>>>>> which is why I'm asking.
>>>>>>>>> >>> Thanks!
>>>>>>>>> >>>
>>>>>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>>>>>>>> e.dimitrova@gmail.com> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> Seems like the 4.1 branch would still require some work to
>>>>>>>>> cover everything raised on this thread? Have anyone evaluated how much work
>>>>>>>>> that can be?
>>>>>>>>> >>>>
>>>>>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then
>>>>>>>>> probably we better have it only in 5.0?
>>>>>>>>> >>>>
>>>>>>>>> >>>> Do people think it makes sense to create some kind of user
>>>>>>>>> survey around this work, too? Posted in @user
>>>>>>>>> >>>>
>>>>>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <
>>>>>>>>> jmckenzie@apache.org> wrote:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>>>>>> backporting to both would increase the risk and maintenance burden.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> It would but by how much?
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Risk: We kind of need to tackle the "version straddle
>>>>>>>>> w/schema table diffs is currently Bad and makes rollbacks manual and
>>>>>>>>> brittle" broadly; this feature is just one more example of that though it's
>>>>>>>>> a little exacerbated by discussing doing something like this in a patch
>>>>>>>>> release. The ergonomics of the "one-way-door without a human manually
>>>>>>>>> deleting columns" part holds true cross-MAJOR too. "Progress" here seems
>>>>>>>>> like it's either we handle this on a case-by-case basis w/flags to remove
>>>>>>>>> those schema entries on rollback (kinda ew), or more durably with an
>>>>>>>>> elegant solution in the long term, i.e. capabilities framework, though that
>>>>>>>>> doesn't answer the "we explode when schemas don't match" bit.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly
>>>>>>>>> more toil than across 2.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit;
>>>>>>>>> I'd like all of us to be able to more freely consider making changes to
>>>>>>>>> schema tables w/out the complexity burden we have right now and the
>>>>>>>>> operator toil and risk that comes along with it.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of
>>>>>>>>> depends on how many people are on 4.0/4.1 right now that we'd expect to be
>>>>>>>>> on 4.1 for another year until 7.0 hits and whether we think they'd benefit
>>>>>>>>> from the feature (and contribute to bettering it) during that year I guess.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>>>>>> backporting to both would increase the risk and maintenance burden.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>>
>>>>>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

[Paulo Motta <pa...@apache.org>]

Thanks Jaydeep and Andy for the review! I have addressed the review
comments and this should be ready for another look.

I wanted to give a heads up to the community that we should be merging this
5.0 backport soon in case there are any outstanding concerns.

On Sun, Feb 22, 2026 at 12:59 AM Tolbert, Andy <x...@andrewtolbert.com> wrote:

> I finally got around to playing around with Paulo's 5.0 backport branch as
> well and added some review feedback.  I agree with Jaydeep that it looks
> great, nice work Paulo!
>
> The write up on the PR in NEWS.txt (
> https://github.com/apache/cassandra/pull/4558/changes#diff-95c20d744db732cdbca24c3e0406c10005ecf7fe8b5719c2fdf2b8af3fcedc79)
> does a great job describing how to opt into the feature and how it
> mitigates any risk.  I'm hopeful that the approach taken here makes a
> giving a +1 to a possible backport vote an easier choice for folks!
>
> Thanks!
> Andy
>
> On Sun, Feb 8, 2026 at 8:03 PM Jaydeep Chovatia <
> chovatia.jaydeep@gmail.com> wrote:
>
>> I have looked at the PR. Overall, it looks great. Added a few comments.
>>
>> Jaydeep
>>
>> On Fri, Jan 30, 2026 at 8:20 PM Jaydeep Chovatia <
>> chovatia.jaydeep@gmail.com> wrote:
>>
>>> I will take a look at it. Happy to see AutoRepair in 5.0.
>>> Thank you for the patch, Paulo!
>>>
>>> Jaydeep
>>>
>>> On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <x...@andrewtolbert.com>
>>> wrote:
>>>
>>>> I'd be happy to take a look at reviewing this as well as I would be
>>>> excited to see Auto Repair in 5.0.  Thank you for the patch, Paulo!
>>>>
>>>> Andy
>>>>
>>>> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org> wrote:
>>>>
>>>>> I have submitted a patch porting AutoRepair to 5.0 on
>>>>> CASSANDRA-21138[1] and tagged Jaydeep Chovatia for review. I would greatly
>>>>> appreciate other sets of eyes, especially those involved with the original
>>>>> CEP-37 effort.
>>>>>
>>>>> The feature is disabled by default and no schema changes are made
>>>>> unless a JVM flag is enabled to reduce upgrade risk to users who do not
>>>>> intend to enable this feature.
>>>>>
>>>>> Please let us know if you have any questions or concerns about having
>>>>> this merged in 5.0.
>>>>>
>>>>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>>>>>
>>>>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <
>>>>> chovatia.jaydeep@gmail.com> wrote:
>>>>>
>>>>>> Sure, I am happy to review it whenever it's ready, Paulo. Please let
>>>>>> me know.
>>>>>>
>>>>>> Jaydeep
>>>>>>
>>>>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org> wrote:
>>>>>>
>>>>>>> I agree with Scott. I don't think we should backport this to 4.1 due
>>>>>>> to the compatibility issues raised plus this branch has already been
>>>>>>> stabilized for a while.
>>>>>>>
>>>>>>> I think backporting auto-repair to 5.0 would be more appropriate as
>>>>>>> it would encourage users to adopt this version and get closer to trunk,
>>>>>>> rather than encouraging users to stick to an older version.
>>>>>>>
>>>>>>> I decided to take a stab at backporting auto-repair +
>>>>>>> additional fixes to 5.0 on this preliminary PR:
>>>>>>> https://github.com/apache/cassandra/pull/4558
>>>>>>>
>>>>>>> It's not ready for review yet since I need to gate the schema
>>>>>>> changes under a feature flag, but I think I can get it ready by the end of
>>>>>>> week.
>>>>>>>
>>>>>>> If there's no opposition against shipping this in 5.0 maybe I can
>>>>>>> create a JIRA and have Jaydeep review it ?
>>>>>>>
>>>>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <
>>>>>>> scott@paradoxica.net> wrote:
>>>>>>>
>>>>>>>> For the purpose of a quick straw poll, I’m not opposed to
>>>>>>>> backporting to 5.x, but I don’t support backporting to 4.x-series releases
>>>>>>>> for the compatibility and upgrade complexity reasons previously discussed.
>>>>>>>>
>>>>>>>> - Scott
>>>>>>>>
>>>>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <
>>>>>>>> smiklosovic@apache.org> wrote:
>>>>>>>> >
>>>>>>>> > Hi everybody,
>>>>>>>> >
>>>>>>>> > I want to refresh this thread after the holidays. Is there an
>>>>>>>> > agreement we reached? Is everybody on board with backporting to
>>>>>>>> 4.1+?
>>>>>>>> > How are we going to do this concretely? I guess Jaydeep would be
>>>>>>>> > involved in the backporting as he just said. I honestly do not
>>>>>>>> think
>>>>>>>> > there is anybody else better suited to make it happen and your
>>>>>>>> > willingness to do that is really appreciated.
>>>>>>>> >
>>>>>>>> > Regards
>>>>>>>> >
>>>>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>>>>>> >> <ch...@gmail.com> wrote:
>>>>>>>> >>
>>>>>>>> >> FYI—regardless of the outcome, you can count on me to port
>>>>>>>> CEP-37 in whatever form the community agrees on. As mentioned earlier, I’m
>>>>>>>> already maintaining a private 4.1.6 fork (
>>>>>>>> https://github.com/apache/cassandra/pull/3367).
>>>>>>>> >> Thank you!
>>>>>>>> >>
>>>>>>>> >> Jaydeep
>>>>>>>> >>
>>>>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com>
>>>>>>>> wrote:
>>>>>>>> >>>
>>>>>>>> >>> I'm really interested in this thread, but don't see an update
>>>>>>>> on where we landed in terms of backporting and also the amount of work
>>>>>>>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>>>>>>>> work and where this discussion goes will really help me optimally plan,
>>>>>>>> which is why I'm asking.
>>>>>>>> >>> Thanks!
>>>>>>>> >>>
>>>>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>>>>>>> e.dimitrova@gmail.com> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> Seems like the 4.1 branch would still require some work to
>>>>>>>> cover everything raised on this thread? Have anyone evaluated how much work
>>>>>>>> that can be?
>>>>>>>> >>>>
>>>>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then
>>>>>>>> probably we better have it only in 5.0?
>>>>>>>> >>>>
>>>>>>>> >>>> Do people think it makes sense to create some kind of user
>>>>>>>> survey around this work, too? Posted in @user
>>>>>>>> >>>>
>>>>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <
>>>>>>>> jmckenzie@apache.org> wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>>>>> backporting to both would increase the risk and maintenance burden.
>>>>>>>> >>>>>
>>>>>>>> >>>>> It would but by how much?
>>>>>>>> >>>>>
>>>>>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>>>>>> >>>>>
>>>>>>>> >>>>> Risk: We kind of need to tackle the "version straddle
>>>>>>>> w/schema table diffs is currently Bad and makes rollbacks manual and
>>>>>>>> brittle" broadly; this feature is just one more example of that though it's
>>>>>>>> a little exacerbated by discussing doing something like this in a patch
>>>>>>>> release. The ergonomics of the "one-way-door without a human manually
>>>>>>>> deleting columns" part holds true cross-MAJOR too. "Progress" here seems
>>>>>>>> like it's either we handle this on a case-by-case basis w/flags to remove
>>>>>>>> those schema entries on rollback (kinda ew), or more durably with an
>>>>>>>> elegant solution in the long term, i.e. capabilities framework, though that
>>>>>>>> doesn't answer the "we explode when schemas don't match" bit.
>>>>>>>> >>>>>
>>>>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly
>>>>>>>> more toil than across 2.
>>>>>>>> >>>>>
>>>>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit;
>>>>>>>> I'd like all of us to be able to more freely consider making changes to
>>>>>>>> schema tables w/out the complexity burden we have right now and the
>>>>>>>> operator toil and risk that comes along with it.
>>>>>>>> >>>>>
>>>>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of
>>>>>>>> depends on how many people are on 4.0/4.1 right now that we'd expect to be
>>>>>>>> on 4.1 for another year until 7.0 hits and whether we think they'd benefit
>>>>>>>> from the feature (and contribute to bettering it) during that year I guess.
>>>>>>>> >>>>>
>>>>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>>>>> backporting to both would increase the risk and maintenance burden.
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>>
>>>>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

["Tolbert, Andy" <x...@andrewtolbert.com>]

I finally got around to playing around with Paulo's 5.0 backport branch as
well and added some review feedback.  I agree with Jaydeep that it looks
great, nice work Paulo!

The write up on the PR in NEWS.txt (
https://github.com/apache/cassandra/pull/4558/changes#diff-95c20d744db732cdbca24c3e0406c10005ecf7fe8b5719c2fdf2b8af3fcedc79)
does a great job describing how to opt into the feature and how it
mitigates any risk.  I'm hopeful that the approach taken here makes a
giving a +1 to a possible backport vote an easier choice for folks!

Thanks!
Andy

On Sun, Feb 8, 2026 at 8:03 PM Jaydeep Chovatia <ch...@gmail.com>
wrote:

> I have looked at the PR. Overall, it looks great. Added a few comments.
>
> Jaydeep
>
> On Fri, Jan 30, 2026 at 8:20 PM Jaydeep Chovatia <
> chovatia.jaydeep@gmail.com> wrote:
>
>> I will take a look at it. Happy to see AutoRepair in 5.0.
>> Thank you for the patch, Paulo!
>>
>> Jaydeep
>>
>> On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <x...@andrewtolbert.com>
>> wrote:
>>
>>> I'd be happy to take a look at reviewing this as well as I would be
>>> excited to see Auto Repair in 5.0.  Thank you for the patch, Paulo!
>>>
>>> Andy
>>>
>>> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org> wrote:
>>>
>>>> I have submitted a patch porting AutoRepair to 5.0 on
>>>> CASSANDRA-21138[1] and tagged Jaydeep Chovatia for review. I would greatly
>>>> appreciate other sets of eyes, especially those involved with the original
>>>> CEP-37 effort.
>>>>
>>>> The feature is disabled by default and no schema changes are made
>>>> unless a JVM flag is enabled to reduce upgrade risk to users who do not
>>>> intend to enable this feature.
>>>>
>>>> Please let us know if you have any questions or concerns about having
>>>> this merged in 5.0.
>>>>
>>>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>>>>
>>>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <
>>>> chovatia.jaydeep@gmail.com> wrote:
>>>>
>>>>> Sure, I am happy to review it whenever it's ready, Paulo. Please let
>>>>> me know.
>>>>>
>>>>> Jaydeep
>>>>>
>>>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org> wrote:
>>>>>
>>>>>> I agree with Scott. I don't think we should backport this to 4.1 due
>>>>>> to the compatibility issues raised plus this branch has already been
>>>>>> stabilized for a while.
>>>>>>
>>>>>> I think backporting auto-repair to 5.0 would be more appropriate as
>>>>>> it would encourage users to adopt this version and get closer to trunk,
>>>>>> rather than encouraging users to stick to an older version.
>>>>>>
>>>>>> I decided to take a stab at backporting auto-repair +
>>>>>> additional fixes to 5.0 on this preliminary PR:
>>>>>> https://github.com/apache/cassandra/pull/4558
>>>>>>
>>>>>> It's not ready for review yet since I need to gate the schema changes
>>>>>> under a feature flag, but I think I can get it ready by the end of week.
>>>>>>
>>>>>> If there's no opposition against shipping this in 5.0 maybe I can
>>>>>> create a JIRA and have Jaydeep review it ?
>>>>>>
>>>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <
>>>>>> scott@paradoxica.net> wrote:
>>>>>>
>>>>>>> For the purpose of a quick straw poll, I’m not opposed to
>>>>>>> backporting to 5.x, but I don’t support backporting to 4.x-series releases
>>>>>>> for the compatibility and upgrade complexity reasons previously discussed.
>>>>>>>
>>>>>>> - Scott
>>>>>>>
>>>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <
>>>>>>> smiklosovic@apache.org> wrote:
>>>>>>> >
>>>>>>> > Hi everybody,
>>>>>>> >
>>>>>>> > I want to refresh this thread after the holidays. Is there an
>>>>>>> > agreement we reached? Is everybody on board with backporting to
>>>>>>> 4.1+?
>>>>>>> > How are we going to do this concretely? I guess Jaydeep would be
>>>>>>> > involved in the backporting as he just said. I honestly do not
>>>>>>> think
>>>>>>> > there is anybody else better suited to make it happen and your
>>>>>>> > willingness to do that is really appreciated.
>>>>>>> >
>>>>>>> > Regards
>>>>>>> >
>>>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>>>>> >> <ch...@gmail.com> wrote:
>>>>>>> >>
>>>>>>> >> FYI—regardless of the outcome, you can count on me to port CEP-37
>>>>>>> in whatever form the community agrees on. As mentioned earlier, I’m already
>>>>>>> maintaining a private 4.1.6 fork (
>>>>>>> https://github.com/apache/cassandra/pull/3367).
>>>>>>> >> Thank you!
>>>>>>> >>
>>>>>>> >> Jaydeep
>>>>>>> >>
>>>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>> I'm really interested in this thread, but don't see an update on
>>>>>>> where we landed in terms of backporting and also the amount of work
>>>>>>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>>>>>>> work and where this discussion goes will really help me optimally plan,
>>>>>>> which is why I'm asking.
>>>>>>> >>> Thanks!
>>>>>>> >>>
>>>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>>>>>> e.dimitrova@gmail.com> wrote:
>>>>>>> >>>>
>>>>>>> >>>> Seems like the 4.1 branch would still require some work to
>>>>>>> cover everything raised on this thread? Have anyone evaluated how much work
>>>>>>> that can be?
>>>>>>> >>>>
>>>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then
>>>>>>> probably we better have it only in 5.0?
>>>>>>> >>>>
>>>>>>> >>>> Do people think it makes sense to create some kind of user
>>>>>>> survey around this work, too? Posted in @user
>>>>>>> >>>>
>>>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org>
>>>>>>> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>>>> backporting to both would increase the risk and maintenance burden.
>>>>>>> >>>>>
>>>>>>> >>>>> It would but by how much?
>>>>>>> >>>>>
>>>>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>>>>> >>>>>
>>>>>>> >>>>> Risk: We kind of need to tackle the "version straddle w/schema
>>>>>>> table diffs is currently Bad and makes rollbacks manual and brittle"
>>>>>>> broadly; this feature is just one more example of that though it's a little
>>>>>>> exacerbated by discussing doing something like this in a patch release. The
>>>>>>> ergonomics of the "one-way-door without a human manually deleting columns"
>>>>>>> part holds true cross-MAJOR too. "Progress" here seems like it's either we
>>>>>>> handle this on a case-by-case basis w/flags to remove those schema entries
>>>>>>> on rollback (kinda ew), or more durably with an elegant solution in the
>>>>>>> long term, i.e. capabilities framework, though that doesn't answer the "we
>>>>>>> explode when schemas don't match" bit.
>>>>>>> >>>>>
>>>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly
>>>>>>> more toil than across 2.
>>>>>>> >>>>>
>>>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit;
>>>>>>> I'd like all of us to be able to more freely consider making changes to
>>>>>>> schema tables w/out the complexity burden we have right now and the
>>>>>>> operator toil and risk that comes along with it.
>>>>>>> >>>>>
>>>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of
>>>>>>> depends on how many people are on 4.0/4.1 right now that we'd expect to be
>>>>>>> on 4.1 for another year until 7.0 hits and whether we think they'd benefit
>>>>>>> from the feature (and contribute to bettering it) during that year I guess.
>>>>>>> >>>>>
>>>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>>>> backporting to both would increase the risk and maintenance burden.
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>>
>>>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

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

I have looked at the PR. Overall, it looks great. Added a few comments.

Jaydeep

On Fri, Jan 30, 2026 at 8:20 PM Jaydeep Chovatia <ch...@gmail.com>
wrote:

> I will take a look at it. Happy to see AutoRepair in 5.0.
> Thank you for the patch, Paulo!
>
> Jaydeep
>
> On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <x...@andrewtolbert.com> wrote:
>
>> I'd be happy to take a look at reviewing this as well as I would be
>> excited to see Auto Repair in 5.0.  Thank you for the patch, Paulo!
>>
>> Andy
>>
>> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org> wrote:
>>
>>> I have submitted a patch porting AutoRepair to 5.0 on CASSANDRA-21138[1]
>>> and tagged Jaydeep Chovatia for review. I would greatly appreciate other
>>> sets of eyes, especially those involved with the original CEP-37 effort.
>>>
>>> The feature is disabled by default and no schema changes are made unless
>>> a JVM flag is enabled to reduce upgrade risk to users who do not intend to
>>> enable this feature.
>>>
>>> Please let us know if you have any questions or concerns about having
>>> this merged in 5.0.
>>>
>>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>>>
>>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <
>>> chovatia.jaydeep@gmail.com> wrote:
>>>
>>>> Sure, I am happy to review it whenever it's ready, Paulo. Please let me
>>>> know.
>>>>
>>>> Jaydeep
>>>>
>>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org> wrote:
>>>>
>>>>> I agree with Scott. I don't think we should backport this to 4.1 due
>>>>> to the compatibility issues raised plus this branch has already been
>>>>> stabilized for a while.
>>>>>
>>>>> I think backporting auto-repair to 5.0 would be more appropriate as it
>>>>> would encourage users to adopt this version and get closer to trunk, rather
>>>>> than encouraging users to stick to an older version.
>>>>>
>>>>> I decided to take a stab at backporting auto-repair + additional fixes
>>>>> to 5.0 on this preliminary PR:
>>>>> https://github.com/apache/cassandra/pull/4558
>>>>>
>>>>> It's not ready for review yet since I need to gate the schema changes
>>>>> under a feature flag, but I think I can get it ready by the end of week.
>>>>>
>>>>> If there's no opposition against shipping this in 5.0 maybe I can
>>>>> create a JIRA and have Jaydeep review it ?
>>>>>
>>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <
>>>>> scott@paradoxica.net> wrote:
>>>>>
>>>>>> For the purpose of a quick straw poll, I’m not opposed to backporting
>>>>>> to 5.x, but I don’t support backporting to 4.x-series releases for the
>>>>>> compatibility and upgrade complexity reasons previously discussed.
>>>>>>
>>>>>> - Scott
>>>>>>
>>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <
>>>>>> smiklosovic@apache.org> wrote:
>>>>>> >
>>>>>> > Hi everybody,
>>>>>> >
>>>>>> > I want to refresh this thread after the holidays. Is there an
>>>>>> > agreement we reached? Is everybody on board with backporting to
>>>>>> 4.1+?
>>>>>> > How are we going to do this concretely? I guess Jaydeep would be
>>>>>> > involved in the backporting as he just said. I honestly do not think
>>>>>> > there is anybody else better suited to make it happen and your
>>>>>> > willingness to do that is really appreciated.
>>>>>> >
>>>>>> > Regards
>>>>>> >
>>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>>>> >> <ch...@gmail.com> wrote:
>>>>>> >>
>>>>>> >> FYI—regardless of the outcome, you can count on me to port CEP-37
>>>>>> in whatever form the community agrees on. As mentioned earlier, I’m already
>>>>>> maintaining a private 4.1.6 fork (
>>>>>> https://github.com/apache/cassandra/pull/3367).
>>>>>> >> Thank you!
>>>>>> >>
>>>>>> >> Jaydeep
>>>>>> >>
>>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>> I'm really interested in this thread, but don't see an update on
>>>>>> where we landed in terms of backporting and also the amount of work
>>>>>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>>>>>> work and where this discussion goes will really help me optimally plan,
>>>>>> which is why I'm asking.
>>>>>> >>> Thanks!
>>>>>> >>>
>>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>>>>> e.dimitrova@gmail.com> wrote:
>>>>>> >>>>
>>>>>> >>>> Seems like the 4.1 branch would still require some work to cover
>>>>>> everything raised on this thread? Have anyone evaluated how much work that
>>>>>> can be?
>>>>>> >>>>
>>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then
>>>>>> probably we better have it only in 5.0?
>>>>>> >>>>
>>>>>> >>>> Do people think it makes sense to create some kind of user
>>>>>> survey around this work, too? Posted in @user
>>>>>> >>>>
>>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org>
>>>>>> wrote:
>>>>>> >>>>>
>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>>> backporting to both would increase the risk and maintenance burden.
>>>>>> >>>>>
>>>>>> >>>>> It would but by how much?
>>>>>> >>>>>
>>>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>>>> >>>>>
>>>>>> >>>>> Risk: We kind of need to tackle the "version straddle w/schema
>>>>>> table diffs is currently Bad and makes rollbacks manual and brittle"
>>>>>> broadly; this feature is just one more example of that though it's a little
>>>>>> exacerbated by discussing doing something like this in a patch release. The
>>>>>> ergonomics of the "one-way-door without a human manually deleting columns"
>>>>>> part holds true cross-MAJOR too. "Progress" here seems like it's either we
>>>>>> handle this on a case-by-case basis w/flags to remove those schema entries
>>>>>> on rollback (kinda ew), or more durably with an elegant solution in the
>>>>>> long term, i.e. capabilities framework, though that doesn't answer the "we
>>>>>> explode when schemas don't match" bit.
>>>>>> >>>>>
>>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly more
>>>>>> toil than across 2.
>>>>>> >>>>>
>>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd
>>>>>> like all of us to be able to more freely consider making changes to schema
>>>>>> tables w/out the complexity burden we have right now and the operator toil
>>>>>> and risk that comes along with it.
>>>>>> >>>>>
>>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of
>>>>>> depends on how many people are on 4.0/4.1 right now that we'd expect to be
>>>>>> on 4.1 for another year until 7.0 hits and whether we think they'd benefit
>>>>>> from the feature (and contribute to bettering it) during that year I guess.
>>>>>> >>>>>
>>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>>> >>>>>
>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>>> backporting to both would increase the risk and maintenance burden.
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>>
>>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

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

I will take a look at it. Happy to see AutoRepair in 5.0.
Thank you for the patch, Paulo!

Jaydeep

On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <x...@andrewtolbert.com> wrote:

> I'd be happy to take a look at reviewing this as well as I would be
> excited to see Auto Repair in 5.0.  Thank you for the patch, Paulo!
>
> Andy
>
> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org> wrote:
>
>> I have submitted a patch porting AutoRepair to 5.0 on CASSANDRA-21138[1]
>> and tagged Jaydeep Chovatia for review. I would greatly appreciate other
>> sets of eyes, especially those involved with the original CEP-37 effort.
>>
>> The feature is disabled by default and no schema changes are made unless
>> a JVM flag is enabled to reduce upgrade risk to users who do not intend to
>> enable this feature.
>>
>> Please let us know if you have any questions or concerns about having
>> this merged in 5.0.
>>
>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>>
>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <
>> chovatia.jaydeep@gmail.com> wrote:
>>
>>> Sure, I am happy to review it whenever it's ready, Paulo. Please let me
>>> know.
>>>
>>> Jaydeep
>>>
>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org> wrote:
>>>
>>>> I agree with Scott. I don't think we should backport this to 4.1 due to
>>>> the compatibility issues raised plus this branch has already been
>>>> stabilized for a while.
>>>>
>>>> I think backporting auto-repair to 5.0 would be more appropriate as it
>>>> would encourage users to adopt this version and get closer to trunk, rather
>>>> than encouraging users to stick to an older version.
>>>>
>>>> I decided to take a stab at backporting auto-repair + additional fixes
>>>> to 5.0 on this preliminary PR:
>>>> https://github.com/apache/cassandra/pull/4558
>>>>
>>>> It's not ready for review yet since I need to gate the schema changes
>>>> under a feature flag, but I think I can get it ready by the end of week.
>>>>
>>>> If there's no opposition against shipping this in 5.0 maybe I can
>>>> create a JIRA and have Jaydeep review it ?
>>>>
>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <sc...@paradoxica.net>
>>>> wrote:
>>>>
>>>>> For the purpose of a quick straw poll, I’m not opposed to backporting
>>>>> to 5.x, but I don’t support backporting to 4.x-series releases for the
>>>>> compatibility and upgrade complexity reasons previously discussed.
>>>>>
>>>>> - Scott
>>>>>
>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <
>>>>> smiklosovic@apache.org> wrote:
>>>>> >
>>>>> > Hi everybody,
>>>>> >
>>>>> > I want to refresh this thread after the holidays. Is there an
>>>>> > agreement we reached? Is everybody on board with backporting to 4.1+?
>>>>> > How are we going to do this concretely? I guess Jaydeep would be
>>>>> > involved in the backporting as he just said. I honestly do not think
>>>>> > there is anybody else better suited to make it happen and your
>>>>> > willingness to do that is really appreciated.
>>>>> >
>>>>> > Regards
>>>>> >
>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>>> >> <ch...@gmail.com> wrote:
>>>>> >>
>>>>> >> FYI—regardless of the outcome, you can count on me to port CEP-37
>>>>> in whatever form the community agrees on. As mentioned earlier, I’m already
>>>>> maintaining a private 4.1.6 fork (
>>>>> https://github.com/apache/cassandra/pull/3367).
>>>>> >> Thank you!
>>>>> >>
>>>>> >> Jaydeep
>>>>> >>
>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> I'm really interested in this thread, but don't see an update on
>>>>> where we landed in terms of backporting and also the amount of work
>>>>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>>>>> work and where this discussion goes will really help me optimally plan,
>>>>> which is why I'm asking.
>>>>> >>> Thanks!
>>>>> >>>
>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>>>> e.dimitrova@gmail.com> wrote:
>>>>> >>>>
>>>>> >>>> Seems like the 4.1 branch would still require some work to cover
>>>>> everything raised on this thread? Have anyone evaluated how much work that
>>>>> can be?
>>>>> >>>>
>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then
>>>>> probably we better have it only in 5.0?
>>>>> >>>>
>>>>> >>>> Do people think it makes sense to create some kind of user survey
>>>>> around this work, too? Posted in @user
>>>>> >>>>
>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org>
>>>>> wrote:
>>>>> >>>>>
>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>> backporting to both would increase the risk and maintenance burden.
>>>>> >>>>>
>>>>> >>>>> It would but by how much?
>>>>> >>>>>
>>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>>> >>>>>
>>>>> >>>>> Risk: We kind of need to tackle the "version straddle w/schema
>>>>> table diffs is currently Bad and makes rollbacks manual and brittle"
>>>>> broadly; this feature is just one more example of that though it's a little
>>>>> exacerbated by discussing doing something like this in a patch release. The
>>>>> ergonomics of the "one-way-door without a human manually deleting columns"
>>>>> part holds true cross-MAJOR too. "Progress" here seems like it's either we
>>>>> handle this on a case-by-case basis w/flags to remove those schema entries
>>>>> on rollback (kinda ew), or more durably with an elegant solution in the
>>>>> long term, i.e. capabilities framework, though that doesn't answer the "we
>>>>> explode when schemas don't match" bit.
>>>>> >>>>>
>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly more
>>>>> toil than across 2.
>>>>> >>>>>
>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd
>>>>> like all of us to be able to more freely consider making changes to schema
>>>>> tables w/out the complexity burden we have right now and the operator toil
>>>>> and risk that comes along with it.
>>>>> >>>>>
>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of
>>>>> depends on how many people are on 4.0/4.1 right now that we'd expect to be
>>>>> on 4.1 for another year until 7.0 hits and whether we think they'd benefit
>>>>> from the feature (and contribute to bettering it) during that year I guess.
>>>>> >>>>>
>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>> >>>>>
>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>>> backporting to both would increase the risk and maintenance burden.
>>>>> >>>>>
>>>>> >>>>>
>>>>>
>>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

["Tolbert, Andy" <x...@andrewtolbert.com>]

I'd be happy to take a look at reviewing this as well as I would be excited
to see Auto Repair in 5.0.  Thank you for the patch, Paulo!

Andy

On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <pa...@apache.org> wrote:

> I have submitted a patch porting AutoRepair to 5.0 on CASSANDRA-21138[1]
> and tagged Jaydeep Chovatia for review. I would greatly appreciate other
> sets of eyes, especially those involved with the original CEP-37 effort.
>
> The feature is disabled by default and no schema changes are made unless a
> JVM flag is enabled to reduce upgrade risk to users who do not intend to
> enable this feature.
>
> Please let us know if you have any questions or concerns about having this
> merged in 5.0.
>
> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138
>
> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <
> chovatia.jaydeep@gmail.com> wrote:
>
>> Sure, I am happy to review it whenever it's ready, Paulo. Please let me
>> know.
>>
>> Jaydeep
>>
>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org> wrote:
>>
>>> I agree with Scott. I don't think we should backport this to 4.1 due to
>>> the compatibility issues raised plus this branch has already been
>>> stabilized for a while.
>>>
>>> I think backporting auto-repair to 5.0 would be more appropriate as it
>>> would encourage users to adopt this version and get closer to trunk, rather
>>> than encouraging users to stick to an older version.
>>>
>>> I decided to take a stab at backporting auto-repair + additional fixes
>>> to 5.0 on this preliminary PR:
>>> https://github.com/apache/cassandra/pull/4558
>>>
>>> It's not ready for review yet since I need to gate the schema changes
>>> under a feature flag, but I think I can get it ready by the end of week.
>>>
>>> If there's no opposition against shipping this in 5.0 maybe I can create
>>> a JIRA and have Jaydeep review it ?
>>>
>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <sc...@paradoxica.net>
>>> wrote:
>>>
>>>> For the purpose of a quick straw poll, I’m not opposed to backporting
>>>> to 5.x, but I don’t support backporting to 4.x-series releases for the
>>>> compatibility and upgrade complexity reasons previously discussed.
>>>>
>>>> - Scott
>>>>
>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <
>>>> smiklosovic@apache.org> wrote:
>>>> >
>>>> > Hi everybody,
>>>> >
>>>> > I want to refresh this thread after the holidays. Is there an
>>>> > agreement we reached? Is everybody on board with backporting to 4.1+?
>>>> > How are we going to do this concretely? I guess Jaydeep would be
>>>> > involved in the backporting as he just said. I honestly do not think
>>>> > there is anybody else better suited to make it happen and your
>>>> > willingness to do that is really appreciated.
>>>> >
>>>> > Regards
>>>> >
>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>>> >> <ch...@gmail.com> wrote:
>>>> >>
>>>> >> FYI—regardless of the outcome, you can count on me to port CEP-37 in
>>>> whatever form the community agrees on. As mentioned earlier, I’m already
>>>> maintaining a private 4.1.6 fork (
>>>> https://github.com/apache/cassandra/pull/3367).
>>>> >> Thank you!
>>>> >>
>>>> >> Jaydeep
>>>> >>
>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> I'm really interested in this thread, but don't see an update on
>>>> where we landed in terms of backporting and also the amount of work
>>>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>>>> work and where this discussion goes will really help me optimally plan,
>>>> which is why I'm asking.
>>>> >>> Thanks!
>>>> >>>
>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>>> e.dimitrova@gmail.com> wrote:
>>>> >>>>
>>>> >>>> Seems like the 4.1 branch would still require some work to cover
>>>> everything raised on this thread? Have anyone evaluated how much work that
>>>> can be?
>>>> >>>>
>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then
>>>> probably we better have it only in 5.0?
>>>> >>>>
>>>> >>>> Do people think it makes sense to create some kind of user survey
>>>> around this work, too? Posted in @user
>>>> >>>>
>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org>
>>>> wrote:
>>>> >>>>>
>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>> backporting to both would increase the risk and maintenance burden.
>>>> >>>>>
>>>> >>>>> It would but by how much?
>>>> >>>>>
>>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>>> >>>>>
>>>> >>>>> Risk: We kind of need to tackle the "version straddle w/schema
>>>> table diffs is currently Bad and makes rollbacks manual and brittle"
>>>> broadly; this feature is just one more example of that though it's a little
>>>> exacerbated by discussing doing something like this in a patch release. The
>>>> ergonomics of the "one-way-door without a human manually deleting columns"
>>>> part holds true cross-MAJOR too. "Progress" here seems like it's either we
>>>> handle this on a case-by-case basis w/flags to remove those schema entries
>>>> on rollback (kinda ew), or more durably with an elegant solution in the
>>>> long term, i.e. capabilities framework, though that doesn't answer the "we
>>>> explode when schemas don't match" bit.
>>>> >>>>>
>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly more
>>>> toil than across 2.
>>>> >>>>>
>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd
>>>> like all of us to be able to more freely consider making changes to schema
>>>> tables w/out the complexity burden we have right now and the operator toil
>>>> and risk that comes along with it.
>>>> >>>>>
>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of
>>>> depends on how many people are on 4.0/4.1 right now that we'd expect to be
>>>> on 4.1 for another year until 7.0 hits and whether we think they'd benefit
>>>> from the feature (and contribute to bettering it) during that year I guess.
>>>> >>>>>
>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>> >>>>>
>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>>> backporting to both would increase the risk and maintenance burden.
>>>> >>>>>
>>>> >>>>>
>>>>
>>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

[Paulo Motta <pa...@apache.org>]

I have submitted a patch porting AutoRepair to 5.0 on CASSANDRA-21138[1]
and tagged Jaydeep Chovatia for review. I would greatly appreciate other
sets of eyes, especially those involved with the original CEP-37 effort.

The feature is disabled by default and no schema changes are made unless a
JVM flag is enabled to reduce upgrade risk to users who do not intend to
enable this feature.

Please let us know if you have any questions or concerns about having this
merged in 5.0.

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

On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia <ch...@gmail.com>
wrote:

> Sure, I am happy to review it whenever it's ready, Paulo. Please let me
> know.
>
> Jaydeep
>
> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org> wrote:
>
>> I agree with Scott. I don't think we should backport this to 4.1 due to
>> the compatibility issues raised plus this branch has already been
>> stabilized for a while.
>>
>> I think backporting auto-repair to 5.0 would be more appropriate as it
>> would encourage users to adopt this version and get closer to trunk, rather
>> than encouraging users to stick to an older version.
>>
>> I decided to take a stab at backporting auto-repair + additional fixes to
>> 5.0 on this preliminary PR: https://github.com/apache/cassandra/pull/4558
>>
>> It's not ready for review yet since I need to gate the schema changes
>> under a feature flag, but I think I can get it ready by the end of week.
>>
>> If there's no opposition against shipping this in 5.0 maybe I can create
>> a JIRA and have Jaydeep review it ?
>>
>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <sc...@paradoxica.net>
>> wrote:
>>
>>> For the purpose of a quick straw poll, I’m not opposed to backporting to
>>> 5.x, but I don’t support backporting to 4.x-series releases for the
>>> compatibility and upgrade complexity reasons previously discussed.
>>>
>>> - Scott
>>>
>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <sm...@apache.org>
>>> wrote:
>>> >
>>> > Hi everybody,
>>> >
>>> > I want to refresh this thread after the holidays. Is there an
>>> > agreement we reached? Is everybody on board with backporting to 4.1+?
>>> > How are we going to do this concretely? I guess Jaydeep would be
>>> > involved in the backporting as he just said. I honestly do not think
>>> > there is anybody else better suited to make it happen and your
>>> > willingness to do that is really appreciated.
>>> >
>>> > Regards
>>> >
>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>>> >> <ch...@gmail.com> wrote:
>>> >>
>>> >> FYI—regardless of the outcome, you can count on me to port CEP-37 in
>>> whatever form the community agrees on. As mentioned earlier, I’m already
>>> maintaining a private 4.1.6 fork (
>>> https://github.com/apache/cassandra/pull/3367).
>>> >> Thank you!
>>> >>
>>> >> Jaydeep
>>> >>
>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com>
>>> wrote:
>>> >>>
>>> >>> I'm really interested in this thread, but don't see an update on
>>> where we landed in terms of backporting and also the amount of work
>>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>>> work and where this discussion goes will really help me optimally plan,
>>> which is why I'm asking.
>>> >>> Thanks!
>>> >>>
>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>>> e.dimitrova@gmail.com> wrote:
>>> >>>>
>>> >>>> Seems like the 4.1 branch would still require some work to cover
>>> everything raised on this thread? Have anyone evaluated how much work that
>>> can be?
>>> >>>>
>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then probably
>>> we better have it only in 5.0?
>>> >>>>
>>> >>>> Do people think it makes sense to create some kind of user survey
>>> around this work, too? Posted in @user
>>> >>>>
>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org>
>>> wrote:
>>> >>>>>
>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>> backporting to both would increase the risk and maintenance burden.
>>> >>>>>
>>> >>>>> It would but by how much?
>>> >>>>>
>>> >>>>> 2 things jump out to me re: risk and maintenance:
>>> >>>>>
>>> >>>>> Risk: We kind of need to tackle the "version straddle w/schema
>>> table diffs is currently Bad and makes rollbacks manual and brittle"
>>> broadly; this feature is just one more example of that though it's a little
>>> exacerbated by discussing doing something like this in a patch release. The
>>> ergonomics of the "one-way-door without a human manually deleting columns"
>>> part holds true cross-MAJOR too. "Progress" here seems like it's either we
>>> handle this on a case-by-case basis w/flags to remove those schema entries
>>> on rollback (kinda ew), or more durably with an elegant solution in the
>>> long term, i.e. capabilities framework, though that doesn't answer the "we
>>> explode when schemas don't match" bit.
>>> >>>>>
>>> >>>>> Maintenance: maintaining this across 4 branches is clearly more
>>> toil than across 2.
>>> >>>>>
>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd
>>> like all of us to be able to more freely consider making changes to schema
>>> tables w/out the complexity burden we have right now and the operator toil
>>> and risk that comes along with it.
>>> >>>>>
>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of
>>> depends on how many people are on 4.0/4.1 right now that we'd expect to be
>>> on 4.1 for another year until 7.0 hits and whether we think they'd benefit
>>> from the feature (and contribute to bettering it) during that year I guess.
>>> >>>>>
>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>> >>>>>
>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>>> backporting to both would increase the risk and maintenance burden.
>>> >>>>>
>>> >>>>>
>>>
>>

Re: [DISCUSS] Backport CEP-37 to all GA branches

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

Sure, I am happy to review it whenever it's ready, Paulo. Please let me
know.

Jaydeep

On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <pa...@apache.org> wrote:

> I agree with Scott. I don't think we should backport this to 4.1 due to
> the compatibility issues raised plus this branch has already been
> stabilized for a while.
>
> I think backporting auto-repair to 5.0 would be more appropriate as it
> would encourage users to adopt this version and get closer to trunk, rather
> than encouraging users to stick to an older version.
>
> I decided to take a stab at backporting auto-repair + additional fixes to
> 5.0 on this preliminary PR: https://github.com/apache/cassandra/pull/4558
>
> It's not ready for review yet since I need to gate the schema changes
> under a feature flag, but I think I can get it ready by the end of week.
>
> If there's no opposition against shipping this in 5.0 maybe I can create a
> JIRA and have Jaydeep review it ?
>
> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <sc...@paradoxica.net>
> wrote:
>
>> For the purpose of a quick straw poll, I’m not opposed to backporting to
>> 5.x, but I don’t support backporting to 4.x-series releases for the
>> compatibility and upgrade complexity reasons previously discussed.
>>
>> - Scott
>>
>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <sm...@apache.org>
>> wrote:
>> >
>> > Hi everybody,
>> >
>> > I want to refresh this thread after the holidays. Is there an
>> > agreement we reached? Is everybody on board with backporting to 4.1+?
>> > How are we going to do this concretely? I guess Jaydeep would be
>> > involved in the backporting as he just said. I honestly do not think
>> > there is anybody else better suited to make it happen and your
>> > willingness to do that is really appreciated.
>> >
>> > Regards
>> >
>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>> >> <ch...@gmail.com> wrote:
>> >>
>> >> FYI—regardless of the outcome, you can count on me to port CEP-37 in
>> whatever form the community agrees on. As mentioned earlier, I’m already
>> maintaining a private 4.1.6 fork (
>> https://github.com/apache/cassandra/pull/3367).
>> >> Thank you!
>> >>
>> >> Jaydeep
>> >>
>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com>
>> wrote:
>> >>>
>> >>> I'm really interested in this thread, but don't see an update on
>> where we landed in terms of backporting and also the amount of work
>> involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026
>> work and where this discussion goes will really help me optimally plan,
>> which is why I'm asking.
>> >>> Thanks!
>> >>>
>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
>> e.dimitrova@gmail.com> wrote:
>> >>>>
>> >>>> Seems like the 4.1 branch would still require some work to cover
>> everything raised on this thread? Have anyone evaluated how much work that
>> can be?
>> >>>>
>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then probably
>> we better have it only in 5.0?
>> >>>>
>> >>>> Do people think it makes sense to create some kind of user survey
>> around this work, too? Posted in @user
>> >>>>
>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org>
>> wrote:
>> >>>>>
>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>> backporting to both would increase the risk and maintenance burden.
>> >>>>>
>> >>>>> It would but by how much?
>> >>>>>
>> >>>>> 2 things jump out to me re: risk and maintenance:
>> >>>>>
>> >>>>> Risk: We kind of need to tackle the "version straddle w/schema
>> table diffs is currently Bad and makes rollbacks manual and brittle"
>> broadly; this feature is just one more example of that though it's a little
>> exacerbated by discussing doing something like this in a patch release. The
>> ergonomics of the "one-way-door without a human manually deleting columns"
>> part holds true cross-MAJOR too. "Progress" here seems like it's either we
>> handle this on a case-by-case basis w/flags to remove those schema entries
>> on rollback (kinda ew), or more durably with an elegant solution in the
>> long term, i.e. capabilities framework, though that doesn't answer the "we
>> explode when schemas don't match" bit.
>> >>>>>
>> >>>>> Maintenance: maintaining this across 4 branches is clearly more
>> toil than across 2.
>> >>>>>
>> >>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd
>> like all of us to be able to more freely consider making changes to schema
>> tables w/out the complexity burden we have right now and the operator toil
>> and risk that comes along with it.
>> >>>>>
>> >>>>> The maintenance toil bit - I have less opinions on. Kind of depends
>> on how many people are on 4.0/4.1 right now that we'd expect to be on 4.1
>> for another year until 7.0 hits and whether we think they'd benefit from
>> the feature (and contribute to bettering it) during that year I guess.
>> >>>>>
>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>> >>>>>
>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
>> backporting to both would increase the risk and maintenance burden.
>> >>>>>
>> >>>>>
>>
>

Re: [DISCUSS] Backport CEP-37 to all GA branches

[Paulo Motta <pa...@apache.org>]

I agree with Scott. I don't think we should backport this to 4.1 due to the
compatibility issues raised plus this branch has already been stabilized
for a while.

I think backporting auto-repair to 5.0 would be more appropriate as it
would encourage users to adopt this version and get closer to trunk, rather
than encouraging users to stick to an older version.

I decided to take a stab at backporting auto-repair + additional fixes to
5.0 on this preliminary PR: https://github.com/apache/cassandra/pull/4558

It's not ready for review yet since I need to gate the schema changes under
a feature flag, but I think I can get it ready by the end of week.

If there's no opposition against shipping this in 5.0 maybe I can create a
JIRA and have Jaydeep review it ?

On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas <sc...@paradoxica.net>
wrote:

> For the purpose of a quick straw poll, I’m not opposed to backporting to
> 5.x, but I don’t support backporting to 4.x-series releases for the
> compatibility and upgrade complexity reasons previously discussed.
>
> - Scott
>
> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <sm...@apache.org>
> wrote:
> >
> > Hi everybody,
> >
> > I want to refresh this thread after the holidays. Is there an
> > agreement we reached? Is everybody on board with backporting to 4.1+?
> > How are we going to do this concretely? I guess Jaydeep would be
> > involved in the backporting as he just said. I honestly do not think
> > there is anybody else better suited to make it happen and your
> > willingness to do that is really appreciated.
> >
> > Regards
> >
> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
> >> <ch...@gmail.com> wrote:
> >>
> >> FYI—regardless of the outcome, you can count on me to port CEP-37 in
> whatever form the community agrees on. As mentioned earlier, I’m already
> maintaining a private 4.1.6 fork (
> https://github.com/apache/cassandra/pull/3367).
> >> Thank you!
> >>
> >> Jaydeep
> >>
> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com>
> wrote:
> >>>
> >>> I'm really interested in this thread, but don't see an update on where
> we landed in terms of backporting and also the amount of work involved.
> I'm all for backporting to 5.x minimally!  I'm planning our 2026 work and
> where this discussion goes will really help me optimally plan, which is why
> I'm asking.
> >>> Thanks!
> >>>
> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <
> e.dimitrova@gmail.com> wrote:
> >>>>
> >>>> Seems like the 4.1 branch would still require some work to cover
> everything raised on this thread? Have anyone evaluated how much work that
> can be?
> >>>>
> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then probably
> we better have it only in 5.0?
> >>>>
> >>>> Do people think it makes sense to create some kind of user survey
> around this work, too? Posted in @user
> >>>>
> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org>
> wrote:
> >>>>>
> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
> backporting to both would increase the risk and maintenance burden.
> >>>>>
> >>>>> It would but by how much?
> >>>>>
> >>>>> 2 things jump out to me re: risk and maintenance:
> >>>>>
> >>>>> Risk: We kind of need to tackle the "version straddle w/schema table
> diffs is currently Bad and makes rollbacks manual and brittle" broadly;
> this feature is just one more example of that though it's a little
> exacerbated by discussing doing something like this in a patch release. The
> ergonomics of the "one-way-door without a human manually deleting columns"
> part holds true cross-MAJOR too. "Progress" here seems like it's either we
> handle this on a case-by-case basis w/flags to remove those schema entries
> on rollback (kinda ew), or more durably with an elegant solution in the
> long term, i.e. capabilities framework, though that doesn't answer the "we
> explode when schemas don't match" bit.
> >>>>>
> >>>>> Maintenance: maintaining this across 4 branches is clearly more toil
> than across 2.
> >>>>>
> >>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd like
> all of us to be able to more freely consider making changes to schema
> tables w/out the complexity burden we have right now and the operator toil
> and risk that comes along with it.
> >>>>>
> >>>>> The maintenance toil bit - I have less opinions on. Kind of depends
> on how many people are on 4.0/4.1 right now that we'd expect to be on 4.1
> for another year until 7.0 hits and whether we think they'd benefit from
> the feature (and contribute to bettering it) during that year I guess.
> >>>>>
> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
> >>>>>
> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and
> backporting to both would increase the risk and maintenance burden.
> >>>>>
> >>>>>
>

Re: [DISCUSS] Backport CEP-37 to all GA branches

["C. Scott Andreas" <sc...@paradoxica.net>]

For the purpose of a quick straw poll, I’m not opposed to backporting to 5.x, but I don’t support backporting to 4.x-series releases for the compatibility and upgrade complexity reasons previously discussed.

- Scott

> On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <sm...@apache.org> wrote:
> 
> Hi everybody,
> 
> I want to refresh this thread after the holidays. Is there an
> agreement we reached? Is everybody on board with backporting to 4.1+?
> How are we going to do this concretely? I guess Jaydeep would be
> involved in the backporting as he just said. I honestly do not think
> there is anybody else better suited to make it happen and your
> willingness to do that is really appreciated.
> 
> Regards
> 
>> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia
>> <ch...@gmail.com> wrote:
>> 
>> FYI—regardless of the outcome, you can count on me to port CEP-37 in whatever form the community agrees on. As mentioned earlier, I’m already maintaining a private 4.1.6 fork (https://github.com/apache/cassandra/pull/3367).
>> Thank you!
>> 
>> Jaydeep
>> 
>>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green <mg...@gmail.com> wrote:
>>> 
>>> I'm really interested in this thread, but don't see an update on where we landed in terms of backporting and also the amount of work involved.  I'm all for backporting to 5.x minimally!  I'm planning our 2026 work and where this discussion goes will really help me optimally plan, which is why I'm asking.
>>> Thanks!
>>> 
>>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <e....@gmail.com> wrote:
>>>> 
>>>> Seems like the 4.1 branch would still require some work to cover everything raised on this thread? Have anyone evaluated how much work that can be?
>>>> 
>>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then probably we better have it only in 5.0?
>>>> 
>>>> Do people think it makes sense to create some kind of user survey around this work, too? Posted in @user
>>>> 
>>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <jm...@apache.org> wrote:
>>>>> 
>>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and backporting to both would increase the risk and maintenance burden.
>>>>> 
>>>>> It would but by how much?
>>>>> 
>>>>> 2 things jump out to me re: risk and maintenance:
>>>>> 
>>>>> Risk: We kind of need to tackle the "version straddle w/schema table diffs is currently Bad and makes rollbacks manual and brittle" broadly; this feature is just one more example of that though it's a little exacerbated by discussing doing something like this in a patch release. The ergonomics of the "one-way-door without a human manually deleting columns" part holds true cross-MAJOR too. "Progress" here seems like it's either we handle this on a case-by-case basis w/flags to remove those schema entries on rollback (kinda ew), or more durably with an elegant solution in the long term, i.e. capabilities framework, though that doesn't answer the "we explode when schemas don't match" bit.
>>>>> 
>>>>> Maintenance: maintaining this across 4 branches is clearly more toil than across 2.
>>>>> 
>>>>> I'm personally kind of keen for us to tackle that Risk bit; I'd like all of us to be able to more freely consider making changes to schema tables w/out the complexity burden we have right now and the operator toil and risk that comes along with it.
>>>>> 
>>>>> The maintenance toil bit - I have less opinions on. Kind of depends on how many people are on 4.0/4.1 right now that we'd expect to be on 4.1 for another year until 7.0 hits and whether we think they'd benefit from the feature (and contribute to bettering it) during that year I guess.
>>>>> 
>>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote:
>>>>> 
>>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and backporting to both would increase the risk and maintenance burden.
>>>>> 
>>>>>