*In theory*, we could: 1. Introduce code that'll look for the new schema entries and gracefully remove them if they're found and you're on version N.M.X 2. Introduce the new schema entries (and feature) in N.M.X+1 3. Also introduce the new feature in N+1.M.X (i.e. next MAJOR) Then you'd have the option of rollback from either the next major (N+1.M.X) or that minor that added the schema (N.M.X+1) back to N.M.X, an isolated point release who's sole function would be culling that new schema.
Which is... not lovely. The idea of there being hard-coded destructive code to revert system schema changes feels... fraught. Outside of making internode system schema mismatches broadly more tolerated though, this might just be a hard requirement of how intolerant our internode schema messaging stuff is post 8099. At least, I can't think of another path off the top of my head. On Wed, Dec 3, 2025, at 2:21 PM, Brandon Williams wrote: > You will still be locked to the version you upgraded to though, since > downgrading will throw exceptions on the now modified schema. If > someone discovers a regression after upgrading, they will be stuck.
