Three times now the published image has lagged main on something a consumer needed, and each was closed by cutting a release — which fixes the instance and leaves the shape alone.
|
What was missing |
Cost |
| #55 |
v0.1.0 predated #42's endpoint corrections |
The published image served four answers known to be wrong |
| #65 |
v0.2.0 and :latest predated -serve-sts |
kubemicrovm-ops built m80 from source in CI to route around it |
| #74 |
v0.3.0 predated -enable-injection by seven hours |
A consumer's whole stand-up crashlooped on the emulator |
Each time the flag existed on main and in no release, and an m80 that does not know a flag exits rather than ignoring it — so a stale tag does not degrade, it crashloops and takes the consumer's stack with it.
#54 carries "the published image matches main" as a criterion. It is true today — git rev-list --count v0.4.0..main is 0 — and it is only ever true at a moment, which is what makes it a poor thing to assert and a good thing to check.
Two candidates
Release on merge to main. The tag stops being a decision. The machinery for deciding whether main is releasable already exists: the release workflow runs the conformance suite against the binary, again against the built container, and scripts/smoke.sh walking the README end to end — all of it rehearsable via workflow_dispatch without publishing. This is a real change in release posture and wants deciding deliberately.
Or fail loudly when it drifts. A scheduled check comparing the flags :latest accepts against the flags main defines, failing when main has one the image does not. That is the exact form all three instances took, and it is a day's work.
What actually contained the last one
Worth recording: #65's fix made the m80 rollout print the binary's own flag list on failure. When #74 hit, the consumer diagnosed a stale image in seconds instead of an afternoon — the error said -serve-sts was there and -enable-injection was not.
That is not prevention, and it is the cheapest thing that has helped so far. It argues for the second option over the first: make the drift visible fast rather than trying to make it impossible.
Three times now the published image has lagged main on something a consumer needed, and each was closed by cutting a release — which fixes the instance and leaves the shape alone.
:latestpredated-serve-sts-enable-injectionby seven hoursEach time the flag existed on main and in no release, and an m80 that does not know a flag exits rather than ignoring it — so a stale tag does not degrade, it crashloops and takes the consumer's stack with it.
#54 carries "the published image matches main" as a criterion. It is true today —
git rev-list --count v0.4.0..mainis 0 — and it is only ever true at a moment, which is what makes it a poor thing to assert and a good thing to check.Two candidates
Release on merge to main. The tag stops being a decision. The machinery for deciding whether main is releasable already exists: the release workflow runs the conformance suite against the binary, again against the built container, and
scripts/smoke.shwalking the README end to end — all of it rehearsable viaworkflow_dispatchwithout publishing. This is a real change in release posture and wants deciding deliberately.Or fail loudly when it drifts. A scheduled check comparing the flags
:latestaccepts against the flags main defines, failing when main has one the image does not. That is the exact form all three instances took, and it is a day's work.What actually contained the last one
Worth recording: #65's fix made the m80 rollout print the binary's own flag list on failure. When #74 hit, the consumer diagnosed a stale image in seconds instead of an afternoon — the error said
-serve-stswas there and-enable-injectionwas not.That is not prevention, and it is the cheapest thing that has helped so far. It argues for the second option over the first: make the drift visible fast rather than trying to make it impossible.