You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The README tells users to write uses: vyncint/launchbound/action@v1, so that tag is what everyone who followed the documentation is actually running. Diffing the action at both refs gives exactly one difference:
Why it is worth fixing — every consumer on the documented ref is gating with reconverge 0.1.11, and moving that pin to 0.3.0 was the entire subject of 1.2.0. The work landed, the release shipped, and it reached nobody who followed the README. vyncint/launchbound-action-demo — the repository that exists to exercise this action — was among them, so the demo has been proving that the old action works.
Nothing was in a position to catch it. The demo uses @v1 on purpose, because a demo should exercise what users copy; this repo's CI has no reason to inspect a tag it does not consume.
Fix — two halves, and only one of them is automatic.
This issue is the one-time catch-up, which no automation can do retroactively:
git tag -f v1 v1.2.0^{commit}
git push -f origin refs/tags/v1
The trigger filter is v[0-9]*.[0-9]*.[0-9]*, so pushing v1 will not re-enter the release workflow.
On the risk — this changes what existing @v1 consumers get, from reconverge 0.1.11 to 0.3.0. That change is already measured: docs/research-baseline.md records the corpus run under both analyzers on the same toolchain — 93 clean, 8 refused, 0 caveats, 0 tool errors, and the two runs byte-identical, same candidate hashes and same REFUSED RC001 reasons. So the gate admits the identical set, and the move is the one users were promised rather than a behaviour change smuggled through a floating tag.
Done when — git rev-parse v1 and git rev-parse v1.2.0^{commit} agree, and launchbound-action-demo's drift check passes.
Today —
refs/tags/v1points at3caa16cb(v1.0.2). Two releases have shipped since:The README tells users to write
uses: vyncint/launchbound/action@v1, so that tag is what everyone who followed the documentation is actually running. Diffing the action at both refs gives exactly one difference:Why it is worth fixing — every consumer on the documented ref is gating with reconverge 0.1.11, and moving that pin to 0.3.0 was the entire subject of 1.2.0. The work landed, the release shipped, and it reached nobody who followed the README.
vyncint/launchbound-action-demo— the repository that exists to exercise this action — was among them, so the demo has been proving that the old action works.Nothing was in a position to catch it. The demo uses
@v1on purpose, because a demo should exercise what users copy; this repo's CI has no reason to inspect a tag it does not consume.Fix — two halves, and only one of them is automatic.
ci(release): move the floating vN tag on publish #12 adds a
float-major-tagjob that movesvNafter a successful publish, so this cannot recur. Merged, it covers 1.2.1 onward.This issue is the one-time catch-up, which no automation can do retroactively:
git tag -f v1 v1.2.0^{commit} git push -f origin refs/tags/v1The trigger filter is
v[0-9]*.[0-9]*.[0-9]*, so pushingv1will not re-enter the release workflow.On the risk — this changes what existing
@v1consumers get, from reconverge 0.1.11 to 0.3.0. That change is already measured:docs/research-baseline.mdrecords the corpus run under both analyzers on the same toolchain — 93 clean, 8 refused, 0 caveats, 0 tool errors, and the two runs byte-identical, same candidate hashes and sameREFUSED RC001reasons. So the gate admits the identical set, and the move is the one users were promised rather than a behaviour change smuggled through a floating tag.Done when —
git rev-parse v1andgit rev-parse v1.2.0^{commit}agree, andlaunchbound-action-demo's drift check passes.