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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >>> [email protected]> 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 <[email protected]> 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 < >>>>> [email protected]> 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č < >>>>>> [email protected]> 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 >>>>>> >> <[email protected]> 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 <[email protected]> >>>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>> 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. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>>
