The Rust programming language is an ambitious project in many ways. With the release of Rust 1.0 on May 15, one might ask, "What's next?" Many words have been written about the technical aspects of how the Rust language achieves its goals of memory safety without garbage collection, but less has been discussed about the project itself and how it is structured. Open source projects are more than just code, and Rust is no exception.
Radical change
Historically, Rust's development has been a story of radical change. If you look at Rust through history, you'll find something peculiar: Rust has had the same mission for its entire existence: a concurrent, safe systems programming language. But the way that Rust has accomplished that has changed significantly since its beginnings, eight years ago.
In order to accommodate these changes, the language's syntax and semantics have also been changing rapidly. This has made Rust hard to learn, as one would need to keep up with a lot of changes in a high-velocity project. As Rust approached the form it presently takes, the team had to address the question: "When will Rust be stable?" As well as an associated and important question: "What does stability mean?"
While stability is a useful thing for users of a programming language, a language that is static is also not useful. Any 1.0 release is not perfect, because no software is ever perfect. At the same time, the previous state wasn't great either, as total change is too chaotic.
Like clockwork and the web
As with any engineering decision, it's important to not only consider your requirements, but examine what others have done when faced with the same problem. The web is another platform which has very strong backwards compatibility guarantees, yet which grows and changes all the time. To work within these constraints, evergreen web browsers have new releases every six weeks with new features and bug fixes, yet remain compatible with the existing web. Many websites themselves follow continuous integration or similar engineering principles, designed to make change easier. While a web application may be deployed dozens of times per day, desktop software updates much more rarely, often once or twice a year at most.
As such, Rust is following a similar path: 1.0 was released on May 15, the 1.1 beta was released at the same time, and the master development branch was advanced to 1.2. Six weeks later, on June 26, Rust 1.1 will come out of beta and become a stable release, 1.2 will be promoted to 1.2-beta, and the master will become the eventual 1.3.
Like clockwork, these updates will come every six weeks. These three releases are called channels, and Rust has three of them: nightly, beta, and stable. A new nightly build is produced from the master branch every 24 hours, while beta and stable releases are only updated as things are backported to their branch. Rust follows the Semantic Versioning principle, which means that these minor releases in the 1.x series will be backwards compatible with previous releases. They will contain new features and bug fixes, but any code you write for 1.0 should work either out of the box or with trivial modification on 1.1.
Not only will this arrangement allow Rust users access to new features and bug fixes quickly, there are secondary effects that will hopefully lead to higher-quality releases as well. For example, consider a project which releases once per year. Over a given year, this project sees two new features, A and B. A appears two months into the cycle and B appears two months before the end of the cycle. With a cycle like this, there is strong incentive to ship feature B, even if it has a few more bugs than usual. While it's had eight less months of testing than feature A, developers love new features, and if feature B misses the release, it'll be a whole year before it can be used.
With a shorter cycle, this pressure is alleviated: If a feature isn't quite ready for an upcoming release, it's just six short weeks before the next one. This prevents features from entering the stable channel if they're not fully-baked.
3 Comments