blairham/stevedore shipped v1.0.0 on 2026-08-18 with a published stability contract and a moving v1 tag. Both shared workflows are still on 0.0.x, and each pins stevedore twice — the action ref and the binary version are separate choices:
| Workflow |
Action ref |
stevedore-version default |
.github/workflows/docker-release.yml |
blairham/stevedore@v0.0.7 (L195) |
v0.0.7, per the comment on L84 |
.github/workflows/docker-release-split.yml |
blairham/stevedore@v0.0.10 (×3: L157, L261, L315) |
"v0.0.10" (L95) |
This is housekeeping, not an incident
v1.0.0 fixed a bug where floating tags (latest, *-latest) were silently withheld from every release on 0.x — a release is cut from a tag, a tag checkout is a detached HEAD, and the default-branch check that gates floating tags could therefore never pass (blairham/stevedore#20).
I checked all 14 of our .stevedore.yaml files and none declares a floating tag, so nothing of ours was ever affected. Recording that here so nobody re-derives it later, and so this issue does not read as urgent — it is not.
The reason to upgrade is the ordinary one: a moving tag means bug fixes arrive without a workflow edit, a breaking change cannot arrive at all, and v1 carries a stability contract that 0.0.x did not.
One thing worth keeping in mind if we ever do add a floating tag: on a shallow checkout the fix cannot work either (there are no branch refs for the commit to be reachable from), but v1 now prints why and names fetch-depth: 0, where 0.x said nothing.
Suggested change
Both files, action ref → blairham/stevedore@v1.
Then drop the stevedore-version defaults entirely and let the input fall through: the action now resolves latest inside its own major line, so @v1 keeps running v1 binaries after a v2 exists. That removes one of the two pins rather than updating it, which is the part that keeps drifting.
The >= v0.0.10 for --split/merge note on L95 can go with it.
Ordering
docker-release-split.yml first, on a low-risk repo (k5s was the first split release), and watch one real release before moving docker-release.yml. The v1 release is verified end to end — :latest, :1.0.0, the moving tags and the Homebrew formula all resolve — but our workflows exercise paths stevedore's own release does not.
Refs: blairham/stevedore#20, blairham/stevedore#21, blairham/stevedore#25
blairham/stevedore shipped v1.0.0 on 2026-08-18 with a published stability contract and a moving
v1tag. Both shared workflows are still on 0.0.x, and each pins stevedore twice — the action ref and the binary version are separate choices:stevedore-versiondefault.github/workflows/docker-release.ymlblairham/stevedore@v0.0.7(L195).github/workflows/docker-release-split.ymlblairham/stevedore@v0.0.10(×3: L157, L261, L315)"v0.0.10"(L95)This is housekeeping, not an incident
v1.0.0 fixed a bug where floating tags (
latest,*-latest) were silently withheld from every release on 0.x — a release is cut from a tag, a tag checkout is a detached HEAD, and the default-branch check that gates floating tags could therefore never pass (blairham/stevedore#20).I checked all 14 of our
.stevedore.yamlfiles and none declares a floating tag, so nothing of ours was ever affected. Recording that here so nobody re-derives it later, and so this issue does not read as urgent — it is not.The reason to upgrade is the ordinary one: a moving tag means bug fixes arrive without a workflow edit, a breaking change cannot arrive at all, and v1 carries a stability contract that 0.0.x did not.
One thing worth keeping in mind if we ever do add a floating tag: on a shallow checkout the fix cannot work either (there are no branch refs for the commit to be reachable from), but v1 now prints why and names
fetch-depth: 0, where 0.x said nothing.Suggested change
Both files, action ref →
blairham/stevedore@v1.Then drop the
stevedore-versiondefaults entirely and let the input fall through: the action now resolveslatestinside its own major line, so@v1keeps running v1 binaries after a v2 exists. That removes one of the two pins rather than updating it, which is the part that keeps drifting.The
>= v0.0.10 for --split/mergenote on L95 can go with it.Ordering
docker-release-split.ymlfirst, on a low-risk repo (k5s was the first split release), and watch one real release before movingdocker-release.yml. The v1 release is verified end to end —:latest,:1.0.0, the moving tags and the Homebrew formula all resolve — but our workflows exercise paths stevedore's own release does not.Refs: blairham/stevedore#20, blairham/stevedore#21, blairham/stevedore#25