Toolchain Policy

Источник: dev/fera/community/TOOLCHAIN.md (read-only; сгенерировано scripts/sync-docs.mjs)

Toolchain Policy

How the Fera project manages the Rust toolchain — when a version bump is allowed, what has to be proven first, and how a breaking bump is handled. Applies to every repo in the the-fera org.

The toolchain is pinned per-repo in rust-toolchain.toml (channel + date, e.g. nightly-2026-09-10). This file is the single source of truth; CI and contributors build against exactly it.

The rule

Before any toolchain bump, we must prove compatibility with all supported prior releases. A bump is never “bump and hope.”

Bump procedure

Test against the supported release line. Build and run the full suite — cargo build, cargo test, cargo clippy --all-targets, cargo fmt --check, plus any repo-specific gates (contract suites, benchmarks, fuzz targets) — on the new toolchain and against every prior release we still support.
If fully compatible: update rust-toolchain.toml and ship it as a normal change. No ceremony.
If anything breaks: a toolchain bump that breaks compatibility is a breaking change and is treated as such:
- it ships on its own, clearly flagged as breaking;
- the change includes an explicit description of what broke, what still works, and a classification of the breakage;
- the classification states the compatibility window: does N-1 still work, or is it a hard break from all older toolchains?

Classification

Every breaking bump states its scope plainly:

N-1 compatible — the previous toolchain still builds and runs the project; only older-than-that is dropped.
Hard break — anything older than the new toolchain no longer works. This is a last resort and needs a recorded reason.

Why

A native client with hot-swappable native modules and a signed trust manifest cannot afford a silently-moving compiler. The toolchain is part of the shipped artifact’s contract; changing it without proving the floor is how a client stops building on a contributor’s machine or ships a miscompile.