

























The Rust team is happy to announce the latest version of Rust, 1.12.1. Rust is a systems programming language with a focus on reliability, performance, and concurrency.
As always, you can install Rust 1.12.1 from the appropriate page on our
website, or install via rustup with rustup update stable.
Wait... one-point-twelve-point... one?
In the release announcement for 1.12 a few weeks ago, we said:
The release of 1.12 might be one of the most significant Rust releases since 1.0.
It was true. One of the biggest changes was turning on a large compiler refactoring, MIR, which re-architects the internals of the compiler. The overall process went like this:
--enable-orbit, was added so that
people working on the compiler could try it out.-Z orbit, to allow users on nightly to try and use MIR
rather than the traditional compilation step ('trans').A change of this magnitude is huge, and important. So it's also important to do
it right, and do it carefully. This is why this process took so long; we
regularly tested the compiler against every crate on crates.io, we asked people
to try out -Z orbit on their private code, and after six weeks of beta, no
significant problems appeared. So we made the decision to keep it on by default
in 1.12.
But large changes still have an element of risk, even though we tried to reduce that risk as much as possible. And so, after release, 1.12 saw a fair number of regressions that we hadn't detected in our testing. Not all of them are directly MIR related, but when you change the compiler internals so much, it's bound to ripple outward through everything.
Now, given that we have a six-week release cycle, and we're halfway towards Rust 1.13, you may wonder why we're choosing to cut a patch version of Rust 1.12 rather than telling users to just wait for the next release. We have previously said something like "point releases should only happen in extreme situations, such as a security vulnerability in the standard library."
The Rust team cares deeply about the stability of Rust, and about our users' experience with it. We could have told you all to wait, but we want you to know how seriously we take this stuff. We think it's worth it to demonstrate our commitment to you by putting in the work of making a point release in this situation.
Furthermore, given that this is not security related, it's a good time to practice actually cutting a point release. We've never done it before, and the release process is semi-automated but still not completely so. Having a point release in the world will also shake out any bugs in dealing with point releases in other tooling as well, like rustup. Making sure that this all goes smoothly and getting some practice going through the motions will be useful if we ever need to cut some sort of emergency point release due to a security advisory or anything else.
This is the first Rust point release since Rust 0.3.1, all the way back in 2012, and marks 72 weeks since Rust 1.0, when we established our six week release cadence along with a commitment to aggressive stability guarantees. While we're disappointed that 1.12 had these regressions, we're really proud of Rust's stability and will to continue expanding our efforts to ensure that it's a platform you can rely on. We want Rust to be the most reliable programming platform in the world.
One thing that you, as a user of Rust, can do to help us fix these issues
sooner: test your code against the beta channel! Every beta release is a
release candidate for the next stable release, so for the cost of an extra
build in CI, you can help us know if there's going to be some sort of problem
before it hits a stable release! It's really easy. For example, on
Travis, you can use this as your .travis.yml:
language: rust
rust:
- stable
- beta
And you'll test against both. Furthermore, if you'd like to make it so that any beta failure doesn't fail your own build, do this:
matrix:
allow_failures:
- rust: beta
The beta build may go red, but your build will stay green.
Most other CI systems, such as AppVeyor, should support something similar. Check the documentation for your specific continuous integration product for full details.
There were nine issues fixed in 1.12.1, and all of those fixes have been backported to 1.13 beta as well.
ethcore crate fails with LLVM errorIn addition, there were four more regressions that we decided not to include in 1.12.1 for various reasons, but we'll be working on fixing those as soon as possible as well.
You can see the full diff from 1.12.0 to 1.12.1 here.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。