Introduction to Rust

Stable, Beta, and Nightly Toolchains

Rust distributes compiler and standard library updates across three release channels—Stable, Beta, and Nightly—following a synchronized six-week train release schedule. Managing these channels with rustup lets you build production software on a rock-solid compiler while testing upcoming releases or experimenting with cutting-edge features.

The Three Release Channels Compared

Channel Release Cadence Stability & Backward Compatibility Unstable #![feature(...)] Gates Primary Audience
Stable Every 6 weeks (on Thursdays) Guaranteed (code that compiles today continues to compile on future stable releases) Forbidden (E0554) All production applications, libraries, and general development
Beta Branched from Nightly every 6 weeks Release candidate for the next Stable version (receives only regression fixes) Forbidden (E0554) CI pipelines testing against the upcoming Stable release before it ships
Nightly Built automatically every night from main Experimental features may change or be removed before stabilization Allowed Contributors testing unstable RFC features, miri, or benchmark harnesses

How the Six-Week Release Train Works

Every six weeks, the release train advances one station forward simultaneously across all three channels:

Time --->   Week 0                   Week 6                   Week 12
            ──────                   ──────                   ───────
Nightly:    1.86.0-nightly  ───────> 1.87.0-nightly  ───────> 1.88.0-nightly
                  │                        │
                  └──> Branches to:        └──> Branches to:
Beta:                  1.86.0-beta  ──────────> 1.87.0-beta
                             │
                             └──> Promoted to:
Stable:                           1.86.0 (Stable Release!)
  1. Daily development (Nightly): All new compiler optimizations, library additions, and experimental features land on the main branch and ship in the next nightly build.
  2. Branching (Nightly -> Beta): Every six weeks, the current nightly tree is branched to become the new beta release, and all #![feature(...)] gates are disabled on that branch.
  3. Promotion (Beta -> Stable): After six weeks of community and Crater testing (compiling hundreds of thousands of crates on crates.io to catch regressions), beta is promoted to the new stable release (for example, 1.85.0 -> 1.86.0). Point releases (such as 1.85.1) are issued between cycles only if critical bugs or security fixes are needed.

Installing and Running Different Channels with rustup

You can install all three channels side by side and invoke any of them on demand:

# Install beta and nightly alongside stable
rustup toolchain install beta nightly

# Check the version of each channel using the `+<channel>` shorthand
rustc +stable --version
rustc +beta --version
rustc +nightly --version

rustc 1.85.0 (4d91de4e4 2025-02-17)
rustc 1.86.0-beta.2 (a1b2c3d4e 2025-02-25)
rustc 1.87.0-nightly (f4a216d28 2025-03-02)

To run cargo with a specific channel for a single command:

cargo +beta test
cargo +nightly check

Pinning a Specific Nightly Date

Because nightly changes every day, you can install a snapshot from a specific calendar date (nightly-YYYY-MM-DD) when reproducing a build:

rustup toolchain install nightly-2025-02-15
cargo +nightly-2025-02-15 build

Feature Gates (#![feature(...)]) on Nightly vs Stable

When a new language feature or standard library API is implemented in rustc, it starts out unstable and is locked behind a crate-level #![feature(name)] attribute.

Attempting to use #![feature(...)] on the Stable or Beta compiler is rejected with E0554 so that unstable features never accidentally leak into stable ecosystem dependencies:

// ❌ does not compile on stable or beta
#![feature(box_patterns)]

fn main() {
    println!("Testing unstable feature gate");
}

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:1:1
  |
1 | #![feature(box_patterns)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error

Once the Rust teams finalize the design of a feature and vote to stabilize it via the RFC process, its #![feature(...)] gate is removed in nightly, rides the next beta train for six weeks, and becomes available to all users on stable without any attribute.