feat: drop schema version tracking entirely#74
Merged
Conversation
Comparison-only variant answering: what if v2 is deleting the record instead of reshaping it? The schema file becomes body-only. schema load marks every migration on disk as applied when bootstrapping a server, trusting that the body reflects disk (the CLI always writes them together). Gains: the merge-conflict hotspot is deleted rather than scattered; no format break (1.x reads a scalar-less schema fine, so no flag day, no guards, no schema upgrade command); the first 2.0 write drops the scalar organically. Gives up: the load-time unrecorded-migrations warning (body/disk drift becomes undetectable) and the bootstrap self-heal (a pending migration is stamped applied on fresh servers instead of being left for migrate). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
effron
force-pushed
the
schema-drop-version-tracking
branch
from
7c87eeb to
51055a0
Compare
schema.yml loses the schema_version field and schema load marks all disk migrations applied instead of skipping unrecorded ones, but old and new binaries interoperate with no coordination, so this ships as a minor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
effron
force-pushed
the
schema-drop-version-tracking
branch
from
0b3b1f4 to
049c158
Compare
effron
changed the title
smudge
approved these changes
Jul 15, 2026
This was referenced Jul 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description:
Every new migration rewrites the schema's
schema_versionline, so any two branches that add migrations conflict on it. Rather than making that line cleverer, this deletes it: the CLI stops writingschema_version, andschema loadmarks every migration on disk as applied instead of comparing against the schema's recorded high-water mark. That's safe because the CLI always writes a migration file and its schema change together, so the schema body already reflects everything in testtrack/migrate.The tradeoff: if someone hand-copies a migration file into testtrack/migrate without its schema change,
schema loadused to print a warning and leave that migration fortesttrack migrateto apply against the new server; now it gets marked applied with no diagnostic. That only bites when a migration bypassedtesttrack createand only on freshly bootstrapped servers.Testing Done:
Ran the new binary against a fresh retail worktree:
create feature_gateworks directly on the existing schema (the diff is just the droppedschema_versionline plus the new split), a 1.9 binary interleaved with the new one round-trips the schema with no errors, andschema loadagainst a stub server marked exactly the 3,366 unique migration versions on disk as applied. Retail's test_track meta specs pass unchanged.