Rust 1.0: current state and final release schedule

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

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

Release Schedule

Based on the progress that we have made during the life of the first alpha, we have compiled an exact timetable for the release of new versions up to 1.0:

• Rust 1.0-alpha2 - February 20
• All modules from 1.0 will be marked stable in nightly builds - around March 9.
• 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 for a second alpha version and only one beta version.
')
The main reason why the next release will be called alpha2, and not beta1, is that we have just approved the new path and IO modules, and would like to collect more community responses 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.

The most important thing is that the API review of all major 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 hold , and temporal |:| notation was declared deprecated.
• Destructors : New destructor rules have been approved, eliminating the need to use the #[unsafe destructor] construct.
• Reform path : The path module was designed from scratch to eliminate many problems with semantics and usability and to take advantage of dynamic size types (DST).
• IO Reform : The io subsystem has been carefully revised to improve stability, cross-platform behavior, and avoid pretentious high-level abstractions over the system. Although almost all APIs were affected by these changes, they were made towards a much more conservative and consistent design.
• Deref coercions : New implicit type conversion mainly affects smart pointers. With it, you can transfer &Vec<T> where &[T] is required, or &Arc<T> where &T is required. These ghosts help get rid of explicit dereferencing and terrible “renegotiation” &* and in general mean that you can now think of & as a general borrowing operator.
  
• Different stages of feature stability : Now in Rust there is an API feature naming system, similar to how we worked with the features of the language. This new concept will help us manage the progress of the standard library and clarify the process of determining the minimum version of Rust required for crate (crate, equivalent to a package or library in the Rust ecosystem) .
• For loops : For more convenient for loops, a new IntoIterator IntoIterator been IntoIterator . Now you can write for x in &vec , instead of for x in vec.iter() .
• Ranges : We have approved the range notation , a construction has been added .. for full ranges, which makes it possible in the future to use an API like collection.remove(..) .
• Traits : New rules of consistency were approved , which allows at the same time to achieve greater flexibility and reasonableness for the implementation of traits.
• Overflow semantics : After much controversy, the semantics of integer overflow was 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 method.
• Associated types : Many bugs with associated types in the compiler have been fixed, now they can be used everywhere.

A few more changes at the time of this writing are not approved, but most likely they will be included in alpha2: covariance and contravariance of types , changes in the Send parameter and changes in the standard library after the reform of integer types in alpha1 .

Details will be described in next week's release notes.

Why another alpha?

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

In more detail, this release highlights the difference between alpha and beta versions associated with our stability system . In alpha releases, you can enable the use of unstable features, but after the beta is released 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 mentioned above, we have approved all the APIs needed 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 working with modified APIs to mark them as stable. The changes in the API, with the exception of a few, are very conservative: they were all made in the image of existing successful libraries.

After alpha2 is released, a long window opens to make changes to the API before they are declared stable. The window closes around March 9th.

Is there a risk of slippage due to the fact that alpha is now released, and not 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 go from alpha2 to stable 1.0.

What else happens before release 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 API, so that you can assign them the label #[stable] .

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

After the deadline of March 9 for a significant part of the crate it will be possible to work only with the "stable Rust", that is, without a single use of the parts of Rust marked with #[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 gaps in the stabilization of the language.

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