Skip to content

fix: the published MSRV was false, and CI now verifies it - #93

Merged
ccross2 merged 1 commit into
mainfrom
fix/msrv-is-false-and-ci-hygiene
Aug 24, 2026
Merged

fix: the published MSRV was false, and CI now verifies it#93
ccross2 merged 1 commit into
mainfrom
fix/msrv-is-false-and-ci-hygiene

Conversation

@ccross2

@ccross2 ccross2 commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

The claim was not stale — it was false

Cargo.toml declared rust-version = "1.75". Measured against the resolved dependency graph:

346 packages, 251 declaring a rust-version
 59 require > 1.75, including DIRECT dependencies:
      ort    1.88
      image  1.88
      zbus   1.87

The true floor is 1.88. The crate could not build on the version it advertised, and anyone who trusted the field got a failure deep inside a dependency rather than a clear "your toolchain is too old". Nothing checked it.

This is the fifth instance in this repository of a claim in one artifact that nothing in another artifact enforces — after the release trigger (#75), the network-isolation claim (#78), and TimeoutStopSec.

A new msrv job reads the version from Cargo.toml, so the manifest stays the single source of truth and the job cannot drift from it. It refuses rather than proceeding if the field is absent — the same failure shape as the release trigger, so it gets the same treatment.

Correction to #87

That PR avoided clippy's suggested as_chunks::<4>() on the grounds that it is stable since 1.88 and would "raise MSRV by thirteen minor versions".

ort already required 1.88. The constraint I was honouring did not exist.

The code is still correct — indexing works on every toolchain and couples to no lint name — but the stated justification overstated the cost. Recorded here rather than quietly dropped, because that reasoning sits in a merged commit message, a PR body and an ADR.

Two CI drift fixes of the same class

  • cargo install cargo-deb pinned to 3.7.0. It produces the shipped artifact, and an unpinned install is exactly the drift that took CI down for six days on 2026-08-24. It happened to resolve to the same version locally and in CI that day — by luck, not design.
  • Both clippy invocations gain --all-targets. The five integration tests added in test: the first integration tests, and a live defect the first one found #91 were clean locally and not linted in CI at all.

Verification

  • actionlint exit 0.
  • The MSRV extraction returns 1.88; a manifest with no rust-version trips the refusal (negative control).
  • fmt clean, clippy --workspace --all-targets -D warnings clean, 93 tests pass, 0 failures.

Not verified locally: that the workspace builds at 1.88. This machine has 1.95 and no 1.88 available. cargo check --workspace --all-targets --locked passes at 1.95, which is a proxy only — the new msrv job is the real check, and this PR is its first run. If it fails, the floor is higher than the metadata declares and the value moves again.

🤖 Generated with Claude Code

Cargo.toml declared rust-version = "1.75". Measured against the resolved
dependency graph, that is not stale — it is false:

  346 packages, 251 declaring a rust-version
   59 require > 1.75, including DIRECT dependencies:
        ort    1.88
        image  1.88
        zbus   1.87

The true floor is 1.88. The crate could not build on the version it advertised,
and anyone who trusted the field got a failure deep inside a dependency rather
than a clear "your toolchain is too old". Nothing checked it.

This is the fifth instance in this repository of a claim in one artifact that
nothing in another artifact enforces — after the release trigger (#75), the
network-isolation claim (#78) and TimeoutStopSec. A new `msrv` job reads the
version from Cargo.toml (so the manifest stays the single source of truth) and
builds at it, refusing rather than proceeding if the field is absent.

CORRECTION TO #87. That commit avoided clippy's suggested `as_chunks::<4>()` on
the grounds that it is stable since 1.88 and would "raise MSRV by thirteen minor
versions". `ort` already required 1.88, so the constraint being honoured did not
exist. The code is still correct — indexing works on every toolchain and couples
to no lint name — but the stated justification overstated the cost. Recorded
here rather than quietly dropped, because that reasoning is in a merged commit
message, a PR body and an ADR.

Also, two CI drift fixes of the same class:

- `cargo install cargo-deb` is pinned to 3.7.0. It produces the SHIPPED
  artifact, and an unpinned install is exactly the drift that took CI down for
  six days on 2026-08-24. It happened to resolve to the same version locally and
  in CI that day by luck, not design.

- Both clippy invocations gain `--all-targets`, so the five integration tests
  added in #91 are actually linted in CI. They were clean locally and invisible
  to CI.

Verified: actionlint exit 0; the MSRV extraction returns 1.88 and a manifest
with no rust-version trips the refusal; fmt clean; clippy --all-targets clean;
93 tests pass, 0 failures.

NOT verified locally: that the workspace builds at 1.88. This machine's
toolchain is 1.95 and no 1.88 is available here. `cargo check --workspace
--all-targets --locked` passes at 1.95, which is a proxy only — the new msrv
job is the real check, and this PR is where it runs for the first time.

Signed-off-by: ccross <cescross2@gmail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@ccross2
ccross2 merged commit ec69fd8 into main Aug 24, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant