v0.34.3: two releases never reached crates.io, and the gate ran too late - #147
Merged
Conversation
`varve` depends on `varve-core` by path AND by version. `cargo package` embeds that requirement, so a stale pin means the published crate asks for a varve-core it was never built against, and `cargo publish` refuses — rightly. A release bumps the workspace `version` and the pin is easy to leave behind: `cargo update -w` does not touch it, because it is a requirement and not a lock entry. I left it behind twice. v0.34.1 and v0.34.2 both shipped GitHub releases and both FAILED to publish, leaving crates.io stranded at 0.34.0 while two tags said otherwise. The binaries, the signed sums and the layer were all correct; only the registry was behind. The invariant was already checked — in publish-crates.yml, which runs only on a tag. A tag is the point of no return: by the time that gate spoke the version was cut and the binaries were published, and the only remedy was another release. The check was right; where it ran was wrong. manifestversions.rs asserts it with `cargo test`, on every pull request and every local run, so a mismatched pin cannot reach a tag. The workflow keeps its own copy of the tag-vs-workspace half, which no unit test can see. The module is gated by `cargo mutants` for the same reason mutationscope.rs is: logic added here later is covered without anyone remembering. Adding the file was itself checked — the v0.34.0 mutation-scope gate refused it until it was declared, which is the first time that gate has caught something that was not planted. This is the fourth instance this week of one shape: an invariant that is real, correct, and enforced somewhere that cannot act on it in time — after the tag here, in the other assembler for `release`, in the wrong directory for the hub staging path, and behind an env-only reader for the realm root. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019TNtfRjLNhEz82G2ggeeNu
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
varvedepends onvarve-coreby path and by version.cargo packageembeds that requirement, so a stale pin means the published crate asks for a
varve-coreit was never built against, andcargo publishrefuses — rightly.cargo update -wdoes not touch the pin, because it is a requirement, not alock entry. v0.34.1 and v0.34.2 both shipped GitHub releases and both failed
to publish, leaving crates.io stranded at
0.34.0while two tags saidotherwise:
Binaries, signed sums and the layer were all correct. Only the registry was
behind.
The check was right; where it ran was wrong
It lives in
publish-crates.yml, which runs only on a tag — the point of noreturn. By the time it spoke, the version was cut and the binaries published,
and the only remedy was another release.
manifestversions.rsasserts the same thing withcargo test, on every PR andevery local run, so a mismatched pin cannot reach a tag. The workflow keeps its
copy of the tag-vs-workspace half, which no unit test can see.
Adding the file was itself checked: the v0.34.0 mutation-scope gate refused it
until declared — the first time that gate has caught something unplanted.
Fourth instance of one shape this week
An invariant that is real, correct, and enforced somewhere that cannot act on it
in time: after the tag here; in the other assembler for
release; in the wrongdirectory for hub staging; behind an env-only reader for the realm root.