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