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