Release channels and feature staging #475

Closed
wants to merge 1 commit into
from

Projects

None yet

9 participants

@brson
Contributor
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
Contributor

😍

@tak1n
tak1n commented Nov 20, 2014

👍

@bstrie bstrie commented on the diff Nov 20, 2014
text/0000-release-channels.md
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+
+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.
+
+# Motivation
+
+We soon intend to [provide stable releases][1] of Rust that offer
+forward compatibility with future releases. Still, we expect to
@bstrie
bstrie Nov 20, 2014 Contributor

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
brson Dec 8, 2014 Contributor

Oops. Good call.

@bstrie bstrie commented on the diff Nov 20, 2014
text/0000-release-channels.md
+
+Under the release train model version numbers are incremented
+automatically each release cycle on a predetermined schedule. Six
+weeks after 1.0.0 is released 1.1.0 will be released, and six weeks
+after that 1.2.0, etc.
+
+The release cycles approaching 1.0.0 will break with this pattern to
+give us leeway to extend 1.0.0 betas for multiple cycles until we are
+confident the intended stability guarantees are in place.
+
+In detail, when the development cycle begins in which we are ready to
+publish the 1.0.0 beta, we will *not* publish anything on the stable
+channel, and the release on the beta channel will be called
+1.0.0-beta1. If 1.0.0 betas extend for multiple cycles, the will be
+called 1.0.0-beta2, -beta3, etc, before being promoted to the stable
+channel as 1.0.0 and beginning the release train process in full.
@bstrie
bstrie Nov 20, 2014 Contributor

Will the "cycles" mentioned in this be six weeks long?

During the 1.0.0-beta period, will there exist separate beta and nightly branches, or will all development be on 1.0.0-beta, with changes reduced to those that are non-catastrophic?

@brson
brson Dec 8, 2014 Contributor

Yes, I seem to have neglected to mention the six week duration. During the beta period there will be active development on nightly and bugfixes on beta as usual. I'll update to mention that.

@bstrie bstrie commented on the diff Nov 20, 2014
text/0000-release-channels.md
+stable 1.0 release cannot be used in any practical sense it will be
+problematic from a PR perspective. Implementing this RFC will require
+careful attention to the libraries it affects.
+
+Recognizing this risk, we must put in place processes to monitor the
+compatibility of known Cargo crates with the stable release channel,
+using evidence drawn from those crates to prioritize the stabilization
+of features and libraries. [This work has already begun][1], with
+popular feature gates being ungated, and library stabilization work
+being prioritized based on the needs of Cargo crates.
+
+Syntax extensions, lints, and any program using the compiler APIs
+will not be compatible with the stable release channel at 1.0 since it
+is not possible to stabilize `#[plugin_registrar]` in time. Plugins
+are very popular. This pain will partially be alleviated by a proposed
+[Cargo] feature that enables Rust code generation.
@bstrie
bstrie Nov 20, 2014 Contributor

I think it should be emphasized that there is an effort to stabilize macro_rules! before 1.0 as an alternative to giving up entirely and resorting to code generation.

@sfackler
sfackler Nov 20, 2014 Member

That's not going to cover procedural macros AFAIK.

@Manishearth
Manishearth Nov 21, 2014 Member

I'm really not fond of forking the plugin process into plugins for nightly and codegen for non-nightly -- codegen is not too clean and will end up polluting larger codebases with hacks to make it work. But I see the necessity of keeping libsyntax hidden.

Would it be possible to selectively allow lint libraries? We can allow these to break -- have them be loaded via Cargo with a mention of the exact Rust release they work with -- if the version is different, they will not be loaded at all (emitting a warning at compile time).

I'm currently working on a bunch of lints for newbies; it would be nice if they could be used by 1.0 users (which probably will be what most newbies use).

Alternatively, if this is implemented, allowing that flag (but making no guarantees on it working) for a release rustc would be fine too. This way it doesn't break libraries, though it may temporarily break workflows.

@brson brson was assigned by nrc Nov 20, 2014
@huonw huonw referenced this pull request in rust-lang/rust Nov 21, 2014
Closed

allow module-level feature flags #9988

@aturon
Contributor
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.

@aturon aturon referenced this pull request in rust-lang/rust Nov 24, 2014
Merged

Mark Any::get_type_id as experimental #19223

@reem
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 aturon referenced this pull request in rust-lang/rust Nov 24, 2014
Closed

Stabilization metabug: 1.0-alpha #19260

140 of 142 tasks complete
@aturon
Contributor
aturon commented Nov 24, 2014

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

@aturon
Contributor
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 SimonSapin referenced this pull request in rust-lang/rust Nov 24, 2014
Closed

Support installing multiple release channels #19263

@SimonSapin
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
Contributor
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