Expand description
beck check --wire-compat — boundary versioning, §4.3.
docs/04-compiler-architecture.md §4.3, which
calls this “a hard requirement, not a nicety”:
During a rolling deploy, old clients talk to new servers. Rules: operation ids are content-derived; a removed operation is retained as a deprecated shim for N releases; the wire format is field-tagged and tolerates unknown fields;
beck check --wire-compat <previous-release>runs in CI and fails on a breaking change without an explicit@breakingmarker. Getting this wrong produces the failure that kills adoption — “the deploy worked but every open browser tab broke.”
§What “compatible” means, precisely
Not “the interface is unchanged” — that would make every release breaking, and a rule nobody can satisfy is a rule everybody turns off. It means: during the window when both versions are live, neither can produce something the other cannot read. There are three populations to keep honest and they have different answers, which is why one rule would be wrong:
| direction | who writes | who reads | so |
|---|---|---|---|
| command | the old client | the new server | the new server must accept every old command |
| event | both versions | the log, forever | neither may write what the other cannot fold |
| state | the fold | its own snapshots | a change needs §3.9’s migrate |
From those three, every rule below follows. A new command variant is compatible: no old client sends it. A removed command variant is breaking: an old tab still has the button. A new event variant is breaking even though nothing old sends one — because §3.1’s exhaustiveness check means an old fold, still running during the rollout, would have no case for it. That asymmetry between commands and events is the interesting part of this file, and it is not obvious from either type on its own; it comes from which side of the boundary each one crosses.
§What this deliberately does not do
It does not diff behaviour, and it does not know about migrate/upcast functions, which are
§3.9’s and Phase 4’s. It compares two published contracts and classifies the differences. That
is the check §4.3 asks CI to run, and it is worth being clear that a green --wire-compat says
“no old client breaks”, not “this deploy is safe”.
Structs§
- Change
- One difference between two releases.
Enums§
- Severity
- How bad a change is.
Functions§
- compare
- Compare a previous release’s interface with this one.
- is_
breaking - Is this release shippable against that one?