|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: "Rust 1.0: Scheduling the trains" |
| 4 | +author: Aaron Turon |
| 5 | +--- |
| 6 | + |
| 7 | +As 2014 is drawing to a close, it's time to begin the Rust 1.0 release cycle! |
| 8 | + |
| 9 | +**TL;DR: we will transition to a six week release cycle on Jan 9, 2015, and |
| 10 | +produce Rust 1.0.0 final at least two cycles afterwards**: |
| 11 | + |
| 12 | +* Rust 1.0.0-alpha -- Friday, Jan 9, 2015 |
| 13 | +* Rust 1.0.0-beta1 -- Week of Feb 16, 2015 |
| 14 | +* Rust 1.0.0 -- One or more six-week cycles later |
| 15 | + |
| 16 | +We talked before about [why Rust is reaching 1.0], and also about the |
| 17 | +[6-week train model] (with Nightly, Beta, and Stable channels) that will enable |
| 18 | +us to deliver stability without stagnation. This post finishes the story by |
| 19 | +laying out the transition to this new release model and the stability guarantees |
| 20 | +it provides. |
| 21 | + |
| 22 | +### The alpha release |
| 23 | + |
| 24 | +Reaching alpha means three things: |
| 25 | + |
| 26 | +* The language is feature-complete. All gates are removed from features we |
| 27 | + expect to ship with 1.0. |
| 28 | + |
| 29 | +* The standard library is nearly feature-complete. The majority of APIs that |
| 30 | + will ship in 1.0 stable will already be marked as `#[stable]`. |
| 31 | + |
| 32 | +* *Warnings* for `#[unstable]` features are turned on by default. (Note that the |
| 33 | + `#[experimental]` stability level is |
| 34 | + [going away](https://github.com/rust-lang/rfcs/pull/507).) |
| 35 | + |
| 36 | +In other words, 1.0.0-alpha gives a pretty accurate picture of what 1.0 will |
| 37 | +look like, but doesn't yet institute release channels. By turning on warnings |
| 38 | +for unstable APIs but not excluding them altogether, we can get community |
| 39 | +feedback about which important APIs still need to be stabilized without those |
| 40 | +APIs simply disappearing over night. |
| 41 | + |
| 42 | +While we expect the pace of breakage to slow dramatically when we reach |
| 43 | +feature-complete status, **1.0.0-alpha is still a [pre-release]**: |
| 44 | + |
| 45 | + A pre-release version indicates that the version is unstable and might not |
| 46 | + satisfy the intended compatibility requirements as denoted by its associated |
| 47 | + normal version. |
| 48 | + |
| 49 | +That is, we will reserve the right to make minor breaking changes to both the |
| 50 | +language and libraries -- including `#[stable]` APIs -- throughout the duration |
| 51 | +of the alpha cycle. But we expect any such changes to be relatively minor |
| 52 | +tweaks, and changes to `#[stable]` APIs to be very rare. |
| 53 | + |
| 54 | +### The beta release(s) |
| 55 | + |
| 56 | +Six weeks later, we will begin the beta period: |
| 57 | + |
| 58 | +* Both the language and libraries are feature-complete. All APIs shipping for |
| 59 | + Rust 1.0 are marked `#[stable]`. |
| 60 | + |
| 61 | +* Release channels take effect: feature gates and `#[unstable]` APIs are |
| 62 | + available on nightly builds, but not on the beta. This change is part of |
| 63 | + [our commitment to stability](http://blog.rust-lang.org/2014/10/30/Stability.html). |
| 64 | + |
| 65 | +Unlike the alpha cycle, where we still expect some minor breakage, the beta |
| 66 | +cycle should *not* involve breakage unless a very significant problem is |
| 67 | +found. Ideally, **the beta cycle will be focused on testing, bugfixing, and |
| 68 | +polish**. |
| 69 | + |
| 70 | +We plan to run at least one beta cycle before the final release. |
| 71 | + |
| 72 | +### The final release |
| 73 | + |
| 74 | +Finally, after one or more beta cycles, we will have produced a release |
| 75 | +candidate that is **ready for the world**: |
| 76 | + |
| 77 | +* We are ready to promise stability -- |
| 78 | + [hassle-free upgrades](http://blog.rust-lang.org/2014/10/30/Stability.html) -- |
| 79 | + for the duration of the 1.X series. |
| 80 | + |
| 81 | +* The core documentation (The Guide/Guides) is fully in sync with the language and |
| 82 | + libraries. |
| 83 | + |
| 84 | +We are incredibly excited for Rust to reach this point. |
| 85 | + |
| 86 | +### What this means for the ecosystem |
| 87 | + |
| 88 | +With the [launch](http://blog.rust-lang.org/2014/11/20/Cargo.html) of Cargo and |
| 89 | +https://crates.io/, Rust's ecosystem has already seen significant expansion, but |
| 90 | +it still takes a lot of work to track Rust's nightly releases. Beginning with |
| 91 | +the alpha release, and especially approaching beta1, this will change |
| 92 | +dramatically; **code that works with beta1 should work with 1.0 final without |
| 93 | +any changes whatsoever**. |
| 94 | + |
| 95 | +This migration into stability should be a boon for library writers, and we hope |
| 96 | +that by 1.0 final there will be a massive collection of crates ready for use on |
| 97 | +the stable channel -- and ready for the droves of people trying out Rust for the |
| 98 | +first time. |
| 99 | + |
| 100 | +Let's do this! |
| 101 | + |
| 102 | +[why Rust is reaching 1.0]: http://blog.rust-lang.org/2014/09/15/Rust-1.0.html |
| 103 | +[6-week train model]: http://blog.rust-lang.org/2014/10/30/Stability.html |
| 104 | +[pre-release]: http://semver.org/ |
0 commit comments