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