Rust 1.0: Scheduling the trains

Dec. 12, 2014 · Aaron Turon

As 2014 is drawing to a close, it's time to begin the Rust 1.0 release cycle!

TL;DR: we will transition to a six week release cycle on Jan 9, 2015, and produce Rust 1.0.0 final at least two cycles afterwards:

  • Rust 1.0.0-alpha -- Friday, Jan 9, 2015
  • Rust 1.0.0-beta1 -- Week of Feb 16, 2015
  • Rust 1.0.0 -- One or more six-week cycles later

We talked before about why Rust is reaching 1.0, and also about the 6-week train model (with Nightly, Beta, and Stable channels) that will enable us to deliver stability without stagnation. This post finishes the story by laying out the transition to this new release model and the stability guarantees it provides.

The alpha release

Reaching alpha means three things:

  • The language is feature-complete. All gates are removed from features we expect to ship with 1.0.

  • The standard library is nearly feature-complete. The majority of APIs that will ship in 1.0 stable will already be marked as #[stable].

  • Warnings for #[unstable] features are turned on by default. (Note that the #[experimental] stability level is going away.)

In other words, 1.0.0-alpha gives a pretty accurate picture of what 1.0 will look like, but doesn't yet institute release channels. By turning on warnings for unstable APIs but not excluding them altogether, we can get community feedback about which important APIs still need to be stabilized without those APIs simply disappearing over night.

While we expect the pace of breakage to slow dramatically when we reach feature-complete status, 1.0.0-alpha is still a pre-release:

A pre-release version indicates that the version is unstable and might not
satisfy the intended compatibility requirements as denoted by its associated
normal version.

That is, we will reserve the right to make minor breaking changes to both the language and libraries -- including #[stable] APIs -- throughout the duration of the alpha cycle. But we expect any such changes to be relatively minor tweaks, and changes to #[stable] APIs to be very rare.

The beta release(s)

Six weeks later, we will begin the beta period:

  • Both the language and libraries are feature-complete. All APIs shipping for Rust 1.0 are marked #[stable].

  • Release channels take effect: feature gates and #[unstable] APIs are available on nightly builds, but not on the beta. This change is part of our commitment to stability.

Unlike the alpha cycle, where we still expect some minor breakage, the beta cycle should not involve breakage unless a very significant problem is found. Ideally, the beta cycle will be focused on testing, bugfixing, and polish.

We plan to run at least one beta cycle before the final release.

The final release

Finally, after one or more beta cycles, we will have produced a release candidate that is ready for the world:

  • We are ready to promise stability -- hassle-free upgrades -- for the duration of the 1.X series.

  • The core documentation (The Guide/Guides) is fully in sync with the language and libraries.

We are incredibly excited for Rust to reach this point.

What this means for the ecosystem

With the launch of Cargo and crates.io, Rust's ecosystem has already seen significant expansion, but it still takes a lot of work to track Rust's nightly releases. Beginning with the alpha release, and especially approaching beta1, this will change dramatically; code that works with beta1 should work with 1.0 final without any changes whatsoever.

This migration into stability should be a boon for library writers, and we hope that by 1.0 final there will be a massive collection of crates ready for use on the stable channel -- and ready for the droves of people trying out Rust for the first time.

Let's do this!