Rust 1.0: current status and final release schedule

Five weeks have passed since the alpha version of Rust 1.0 was released! Before the next preliminary version of Rust is released, we would like to talk about the current state of the language and what we still intend to do along the way to the stable version 1.0.

TL; DR: Rust 1.0 will be released May 15, 2015

Release Schedule

Based on the progress that we made during the life of the first alpha, we made an accurate schedule for the release of new versions to 1.0:

• Rust 1.0-alpha2 - February 20
• All modules from 1.0 will be marked stable in nightly builds - around March 9th
• Rust 1.0-beta - March 31
• Rust 1.0 - May 15

This schedule differs from the previous one in that we fixed a certain set of development cycles. Also, the new schedule provides a second alpha version and only one beta version.

The main reason the next release will be called alpha2 rather than beta1 is because we just approved the new path and IO modules and would like to get more community feedback before declaring them stable.

What's New in alpha2

We managed to approve and implement almost all the features that were planned for this development cycle.

Most importantly, the revision of the API of all the main subsystems has been completed: the path and IO modules have been reformed. Now all the modules that we want to include in 1.0 have taken their final form (although minor edits are possible during the alpha2 cycle).

Other changes and improvements:

• Closures : Rust now supports closures with full capture , and the temporary |:|notation has been declared deprecated.
• Destructors : New rules for destructors have been approved , eliminating the need to use constructs #[unsafe destructor].
• Path reform : The module pathwas designed from the ground up to eliminate many semantics and usability issues and to take advantage of dynamic size (DST) types.
• IO Reform : The subsystem has iobeen carefully revised to improve stability, cross-platform behavior, and avoid pretentious high-level abstractions over the system. Although almost all of the APIs were affected by these changes, they were made towards a much more conservative and consistent design.
• Deref coercions : New implicit casts affect mostly smart pointers. With it, you can transmit where required , or where required . These casts help get rid of explicit dereferencing and terrible "borrowing" and generally mean that now you can think of as a general borrowing operator.&Vec&[T]&Arc&T&*&
  
• Various stages of feature stability : Now Rust has a feature API naming system similar to how we worked with language features. This new concept will help us manage the progress of the standard library and will make it more clear the process of determining the minimum version of Rust needed for a crate (crate, analogue of a package or library in the Rust ecosystem - approx. Per.) .
• For loops : A new trait has been introduced for more convenient for loops IntoIterator. Now you can write for x in &vec, instead for x in vec.iter().
• Ranges : We have approved the range notation , the design ..for full ranges has been added , which makes it possible to use an API like in the future collection.remove(..).
• Traits : New rules for consistency have been approved , which allows both greater flexibility and validity for trait implementations.
• Overflow semantics : After much debate, the semantics of integer overflow has been approved (to be implemented in alpha2). It is designed to greatly simplify the search for overflow bugs, especially when used in conjunction with the fuzzing technique.
• Associated types : A lot of bugs with associated types in the compiler have been fixed, now they can be used everywhere.

Some more changes at the time of writing are not approved, but are likely to be included in alpha2: covariance and contravariance of types , changes in the Send trait and changes in the standard library after the reform of integer types in alpha1 .

Details will be described in the release notes next week.

Why another alpha?

The main reason is that we want to leave those APIs that we recently approved (for example, IO and path) that are marked unstable for several weeks in order to get feedback. In beta, we are going to generally ban the use of unstable parts of Rust.

In more detail, this release highlights the difference between the alpha and beta versions associated with our stability system . In alpha releases, you can enable the use of unstable features, but after the beta release this will be possible only when using nightly builds. The beta release will be the point when a significant part of the community can get away from using nightly builds.

As stated above, we have approved all the APIs required for release 1.0, including path and IO. However, some changes were accepted only at the end of the cycle and the community does not have enough experience with modified APIs to mark them stable. Changes to the API, with the exception of a few, are very conservative: they were all made in the likeness of existing successful libraries.

After alpha2 exits, a long window will open for making changes to the API before they are declared stable. The window will close on March 9th.

Is there a risk of slippage due to alpha being released instead of beta?

Unlikely. All features of the language and standard library required for release 1.0 are approved. This means that we have 12 weeks to polish everything and quietly switch from alpha2 to stable 1.0.

What else will happen before the release of 1.0?

All features 1.0 are already approved. It remains only to grind, improve performance and documentation, fix bugs and gain enough confidence in the new APIs so that you can label them #[stable].

The release of alpha2 will mark deprecated (but will leave available) the old path and IO modules. New modules should become stable by March 9th. Please try the new APIs and help us identify potential issues!

After the deadline of March 9, for a significant part of the racks it will become possible to work only with “stable Rust”, that is, without a single use of the parts marked#[feature]. After the deadline, and before the release of beta version 1.0, we intend to work directly with the authors of the packages for crates.io to help translate their code to stable Rust and identify all the gaps in language stabilization.

We hope that by the time beta is released, a significant part of the ecosystem will move from nightly builds to stable releases. To achieve this, the whole community needs to move towards stabilization, which we coordinate with discuss . If you have not yet joined this process, please go there and tell us which key unstable APIs you use.