Skip to content

feat(ir)!: bump IRVersion to 0.4.0 for the stack's shape changes - #442

Open
fuad-daoud wants to merge 1 commit into
stack/7-review-fixesfrom
stack/8-irversion
Open

feat(ir)!: bump IRVersion to 0.4.0 for the stack's shape changes#442
fuad-daoud wants to merge 1 commit into
stack/7-review-fixesfrom
stack/8-irversion

Conversation

@fuad-daoud

Copy link
Copy Markdown
Collaborator

Breaking, and this is the commit that makes the whole stack safe to merge.

Six commits below this one change the JSON shape of a Document, and none bumped IRVersion — each correctly deferring, because ir-design.md §2.1 says a line of work bumps it once, where it lands on main. This is that bump. Without it the stack lands at 0.3.0.

Nothing in the gate can see this. TestVerify_CurrentIRVersionIsClean, TestVerify_IncompatibleIRVersionIsAViolation and openapi_test.go all compare against the same constant, so they stay green whatever it says. It was found by review, not by CI — and the GoDoc names precisely this failure:

a shape change that reaches main without a bump leaves a consumer pinned to the old version accepting a document it cannot read, which is the one thing this constant exists to prevent

The log paragraph records all six, each framed as what a 0.3.0 consumer gets wrong rather than as a feature: ErrorCase loses type; Payload gains required; Parameter gains provenance; Deprecation gains removalDate; Encoding gains schema; and exclusiveMin/exclusiveMax change JSON type — the one that fails a decode rather than degrading it.

TestCompatibleVersion's neighbour rows were spelled against 0.3.0, so the bump made "a later generation" literally 0.4.0 — the row asserted the build rejects its own documents. Re-anchored, with a comment saying they move with the constant.

79 goldens regenerated; the only key that moved is irVersion.

BREAKING CHANGE: documents stamp 0.4.0 and CompatibleVersion refuses 0.3.0. Consumers recompile rather than migrate stored documents.


Stack 8 of 8. Base stack/7-review-fixes — review and merge bottom-up. Every commit here passed make gate when it landed, and the full gate was re-run on the top of the stack. Run it as GOTOOLCHAIN=go1.26.3 make gate; this machine's Go 1.27 fails it for reasons unrelated to any change (#431).

🤖 Generated with Claude Code

https://claude.ai/code/session_01SYeBgDsskwnyitLgPGCPn1

Six commits on this branch change the JSON shape of a Document and none
bumped the constant, each correctly deferring per ir-design 2.1: a line of
work bumps it ONCE, where it lands on main. This is that bump.

The GoDoc on IRVersion names exactly the failure a missing bump causes -- "a
shape change that reaches main without a bump leaves a consumer pinned to the
old version accepting a document it cannot read, which is the one thing this
constant exists to prevent" -- and nothing in the gate can see it, because
TestVerify_CurrentIRVersionIsClean, TestVerify_IncompatibleIRVersionIsAViolation
and openapi_test.go all compare against the same constant and stay green
whatever it says. Found by review, not by CI.

The log paragraph records all six, each framed as what a 0.3.0 consumer gets
wrong rather than as a feature: ErrorCase loses Type and gains Name/Payload/
Headers; Payload gains Required; Parameter gains Provenance; Deprecation gains
RemovalDate and x-sunset routes there; Encoding gains Schema; and
Constraints.ExclusiveMin/Max change from bool to a decimal string, which is
the one that fails a consumer's decode rather than degrading it.

TestCompatibleVersion's neighbour rows were spelled against 0.3.0, so the
bump made "a later generation" 0.4.0 assert that the build rejects its own
documents. Re-anchored, with a comment saying they move with the constant.

79 goldens regenerated; the only key that moved is irVersion.

BREAKING CHANGE: IR documents now stamp 0.4.0 and CompatibleVersion refuses
0.3.0. Consumers must recompile rather than migrate stored documents.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SYeBgDsskwnyitLgPGCPn1
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.

2 participants