Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release channels and feature staging #475

Closed
wants to merge 1 commit into from

Conversation

brson
Copy link
Contributor

@brson brson commented Nov 20, 2014

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
Copy link
Member

😍

@tak1n
Copy link

tak1n commented Nov 20, 2014

👍

# Motivation

We soon intend to [provide stable releases][1] of Rust that offer
forward compatibility with future releases. Still, we expect to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Good call.

@aturon
Copy link
Member

aturon commented Nov 24, 2014

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:

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
Copy link

reem commented Nov 24, 2014

@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
Copy link
Member

aturon commented Nov 24, 2014

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

@aturon
Copy link
Member

aturon commented Nov 24, 2014

@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
Copy link
Contributor

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
Copy link
Contributor Author

brson commented Dec 8, 2014

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

@brson brson closed this Dec 8, 2014
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.

10 participants