Skip to content

chore: pin the toolchain to 1.97.1 instead of floating on stable - #268

Merged
forkwright merged 1 commit into
mainfrom
chore/pin-fleet-toolchain
Aug 16, 2026
Merged

chore: pin the toolchain to 1.97.1 instead of floating on stable#268
forkwright merged 1 commit into
mainfrom
chore/pin-fleet-toolchain

Conversation

@forkwright

Copy link
Copy Markdown
Owner

What

rust-toolchain.toml: channel = "stable"channel = "1.97.1".

Why stable is not a pin

It names whatever each host last downloaded, so it is a different compiler per machine and drifts on its own with no commit. Measured on metis:

$ rustup run stable rustc --version
rustc 1.95.0 (59807616e 2026-04-14)

$ rustup check
stable - update available: 1.95.0 (2026-04-14) -> 1.97.1 (2026-07-14)

So a local check compiles with 1.95.0 while CI installs stable fresh and gets 1.97.1 — two minor versions of new clippy lints between the compiler a change is verified with and the compiler that gates its merge. Under -D warnings such a lint is invisible locally and fatal in CI, and it presents as a broken local tool rather than a version gap.

A floating pin is worse than a stale fixed one. A repo on an old fixed version is at least reproducible and its divergence is legible; stable diverges from itself across hosts and across time with nothing recording it.

Why 1.97.1

It is the current stable and the pin kanon and typikon already use, so this converges rather than adding a ninth fleet toolchain. Fleet context: forkwright/kanon#3336.

Scope

One line plus its rationale comment. No workflow passes an explicit toolchain: to a gate job here, so this file is already what they honour — nothing else needs changing. The single nightly in the repo is codeql.yml's rust_toolchain input to the shared analyzer; it does not read this file and is untouched.

Expected fallout

Possibly none, possibly a handful of new lints from 1.96/1.97 arriving at once. CI is the judge — that is the point of the change, and any lints it surfaces are ones that were already going to fire, just at an unpredictable moment instead of this one.

Refs forkwright/kanon#3336

`stable` is not a version -- it names whatever each host last downloaded. metis
resolved it to 1.95.0 while CI installed 1.97.1, so two minor versions of new
clippy lints sat between the compiler a change is checked with and the compiler
that gates its merge. Under `-D warnings` such a lint is invisible locally and
fatal in CI, and it presents as a broken local tool rather than a version gap.

A floating pin is therefore worse than a stale fixed one: a stale pin is at
least reproducible and legible, while `stable` diverges from itself across hosts
and across time with nothing recording it.

1.97.1 matches kanon and typikon and is the current stable. No workflow passes
an explicit `toolchain:` to a gate job, so this file is what they honour. The
one `nightly` in the repo is `codeql.yml`'s `rust_toolchain` input to the shared
analyzer, which is unaffected by this file and stays as it is.

Refs forkwright/kanon#3336
@forkwright
forkwright merged commit a603e52 into main Aug 16, 2026
10 checks passed
@forkwright
forkwright deleted the chore/pin-fleet-toolchain branch August 16, 2026 20:50
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