The feature could be back ported defaulting off. No schema changes would be made when it is off, but it would recognize the changes if they existed and be ok with it. If someone turns it on then the schema changes are made.
That way you don’t need multiple versions to do it, and you support safe upgrade/rollback to even version 4.1.27 from 4.1.0. -Jeremiah On Wed, Dec 3, 2025 at 2:37 PM Josh McKenzie <[email protected]> wrote: > *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. > > >
