Release channels and feature staging

[brson]

This RFC describes changes to the Rust release process, primarily the division of Rust's time-based releases into 'release channels', following the 'release train' model used by e.g. Firefox and Chrome; as well as 'feature staging', which enables the continued development of experimental language features and libraries APIs while providing strong stability guarantees in stable releases.

Rendered.

[steveklabnik]

😍

[tak1n]

👍

[bstrie]

I don't think "forward compatibility" is the phrase you want here, which to me implies that a Rust 1.0 compiler would be able to compile code written for later versions.

[brson]

Oops. Good call.

[aturon]

I'm really excited to move to this model; thanks for nailing down the details, @brson.

One thing I wanted to clarify in terms of the 1.0.0 beta period: we are planning to run at least two beta cycles.

During the first cycle, we plan to turn on the stability lints, but not to add the #[staged_api] attribute. That will mean that the beta channel will allow you to use #[experimental] and #[unstable] features, but will warn you when you do so. This cycle will serve to discover gaps in API stabilization -- important APIs that are not yet #[stable] for the initial beta -- and also give us a little bit more time on the trickiest #[unstable] APIs.

The second cycle will then add #[staged_api], so that the 1.0.0-beta2 will serve as a true release candidate.

By the time we release the first beta, we expect the bulk of std to be #[stable], with the possible exception of std::io:

• The basic types are nearly all #[unstable] (awaiting second pass) or #[stable] already
• Runtime reform
• Collections reform
• Numerics reform
• Formatting stabilization
• cmp/ops reform
• Macro reform
• Path reform
• Thread-local storage reform
• std::sync and std::task (to become std::thread) under development

By the second cycle, there should be very little large-scale API revision. Thus, the two cycles should serve as a period of relative calm (compared to today's very rapid breakage) during which the crates.io ecosystem can stabilize and grow before the stable 1.0 release.

[reem]

@aturon That sounds like a very reasonable plan.

How will cargo support package verification for stable and unstable packages which use the stable and nightly releases, respectively? Obviously a nightly package may not build on stable, but I think it should still be reachable from crates.io.

[aturon]

I've created a stabilization metabug, for those wanting to get a better sense of the current status.

[aturon]

@reem

How will cargo support package verification for stable and unstable packages which use the stable and nightly releases, respectively? Obviously a nightly package may not build on stable, but I think it should still be reachable from crates.io.

I can't answer this, but I bet that @alexcrichton can!

[SimonSapin]

Release channels are great, and I want all of them on my laptop. So I filed rust-lang/rust#19263 about fixing the installer to support that without messing with $PATH and $LD_LIBRARY_PATH.

[brson]

I've made a significant revision to this in a new PR, which takes into account the comments made here: #507.