Cargo.lock is in .gitignore, so every CI run resolves dependencies afresh. That is the correct default for a library; loom ships binaries, where the standard guidance is the opposite — commit the lock so the build is reproducible and dependency changes arrive as reviewable diffs.
What it has actually cost
Four red-main incidents this cycle, none of them caused by a code change:
| what floated |
effect |
rand 0.9 → 0.10 |
thread_rng/RngCore removed; loom-testing stopped compiling |
| nightly fuzz deps |
fuzz build broke intermittently (build failure, not a crash) |
ordeal 0.9.1 → 0.15.0 (auto-merged) |
a pin test asserting the old behaviour flipped to failing; main red for days |
cranelift-isle 0.132 → 0.134 (three times: #298, #310, #318) |
MSRV 1.94 > CI's 1.93.1 → wasm32-wasip2 build red |
The cranelift case is the clearest argument. It has now been re-floated three times past a comment in Cargo.toml explaining precisely why not to, because the bumps auto-merge and Dependabot does not read comments. Each time the fix was a per-pin patch; the third time it arrived through a different ecosystem entry (/fuzz) than the ignore that was supposed to stop it. Per-pin ignores are whack-a-mole against an automated player.
Why the lockfile is the actual fix
A committed lock does not stop upgrades — it changes when they are decided. Today a transitive bump lands on main and is discovered by a red build; with a lock it lands as a PR whose CI must be green before merge. Same upgrades, gated instead of ambient.
It also fixes reproducibility, which matters more here than in a typical binary: this project's claims are of the form "N/N rules proven, 481 tests pass, these are the trusted axioms". Those numbers are only meaningful against a known dependency set. A verification tool whose solver version floats is publishing measurements it cannot reproduce.
Scope
- Remove
Cargo.lock from .gitignore, commit the resolved lock.
- Keep Dependabot enabled — the point is gated updates, not frozen ones.
- Once the lock is in place, the per-pin
ignore entries for cranelift-isle become removable (the lock holds the version; CI proves the bump before it lands). Remove them in the same change or immediately after, so the mechanism is one thing rather than two.
Correction
Several existing comments — Cargo.toml, .github/dependabot.yml, and commentary on #311/#313 — cite "#142" as the lockfile issue. That was a mis-citation on my part: #142 is "Restore release-binary uploads + adopt unified release artifact standard" and is closed, so those pointers read as "already handled" when nothing of the sort exists. This issue is the real referent and those references are being corrected to point here.
Cargo.lockis in.gitignore, so every CI run resolves dependencies afresh. That is the correct default for a library; loom ships binaries, where the standard guidance is the opposite — commit the lock so the build is reproducible and dependency changes arrive as reviewable diffs.What it has actually cost
Four red-main incidents this cycle, none of them caused by a code change:
rand0.9 → 0.10thread_rng/RngCoreremoved;loom-testingstopped compilingordeal0.9.1 → 0.15.0 (auto-merged)cranelift-isle0.132 → 0.134 (three times: #298, #310, #318)wasm32-wasip2build redThe cranelift case is the clearest argument. It has now been re-floated three times past a comment in
Cargo.tomlexplaining precisely why not to, because the bumps auto-merge and Dependabot does not read comments. Each time the fix was a per-pin patch; the third time it arrived through a different ecosystem entry (/fuzz) than the ignore that was supposed to stop it. Per-pin ignores are whack-a-mole against an automated player.Why the lockfile is the actual fix
A committed lock does not stop upgrades — it changes when they are decided. Today a transitive bump lands on main and is discovered by a red build; with a lock it lands as a PR whose CI must be green before merge. Same upgrades, gated instead of ambient.
It also fixes reproducibility, which matters more here than in a typical binary: this project's claims are of the form "N/N rules proven, 481 tests pass, these are the trusted axioms". Those numbers are only meaningful against a known dependency set. A verification tool whose solver version floats is publishing measurements it cannot reproduce.
Scope
Cargo.lockfrom.gitignore, commit the resolved lock.ignoreentries forcranelift-islebecome removable (the lock holds the version; CI proves the bump before it lands). Remove them in the same change or immediately after, so the mechanism is one thing rather than two.Correction
Several existing comments —
Cargo.toml,.github/dependabot.yml, and commentary on #311/#313 — cite "#142" as the lockfile issue. That was a mis-citation on my part: #142 is "Restore release-binary uploads + adopt unified release artifact standard" and is closed, so those pointers read as "already handled" when nothing of the sort exists. This issue is the real referent and those references are being corrected to point here.