Skip to content

ci: refuse a schema change an older lerd cannot read - #87

Merged
geodro merged 1 commit into
mainfrom
ci/schema-guard
Sep 20, 2026
Merged

geodro merged 1 commit into
mainfrom
ci/schema-guard

Conversation

@geodro

@geodro geodro commented Sep 20, 2026

Copy link
Copy Markdown
Member

Definitions here reach every install within a day whatever version of lerd is running, and there is no version gate on the way in, so an old binary will happily read a definition written long after it shipped. That makes backward compatibility a property of how the schema is allowed to change rather than something a release can fix afterwards, and the pull request is the only moment to catch a change that breaks it, since a merge is on everyone's machine the next day with no way to roll it back per install.

This adds a check that flattens every document to a set of paths and types, compares the branch against what is published on main, and fails on the two changes an old binary cannot survive: a key that disappeared, and a key whose type moved under it. A value no published definition has used before comes out as a warning rather than a failure, because widening what a key accepts breaks an old switch exactly as retyping does, but only the author can say whether the binaries already out there know the new value.

Both the types and the closed value sets are inferred from the published tree itself, so there is no schema file to keep in sync as definitions grow.

The Go side of the same rule is lerd-env/lerd#1911, which makes lerd refuse a value it does not recognise instead of defaulting past it.

Definitions here reach every install within a day, whatever version of lerd is running, and there is no version gate on the way in. An old binary will read a definition written long after it shipped, so the schema may only grow, and the moment to catch a change that breaks that is the pull request rather than the day after it ships.

The guard flattens every document to a set of paths and types, compares the branch against what is published, and fails on the two changes an older binary cannot survive: a key that disappeared, and a key whose type moved under it. A value no published definition has used before is reported as a warning instead, because widening the accepted values of a key breaks an old switch exactly as retyping does, but only the author knows whether the binaries in the field already understand it.

Both the types and the closed value sets come from the published tree itself, so nothing here needs updating as the schema grows.
@geodro
geodro requested a review from a team as a code owner September 20, 2026 17:55
@geodro
geodro merged commit c209a78 into main Sep 20, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant