附录 G - Rust 是如何开发的与“Nightly Rust”
Appendix G - How Rust is Made and “Nightly Rust”
本附录介绍 Rust 是如何开发的，以及这对作为 Rust 开发者的你有什么影响。
This appendix is about how Rust is made and how that affects you as a Rust developer.
稳步前行（Stability Without Stagnation）
Stability Without Stagnation
作为一个语言，Rust 非常看重代码的稳定性。我们希望 Rust 成为你可以信赖的坚实基石，如果事物总是在变动，那是不可能的。与此同时，如果我们不能试验新特性，我们可能直到发布之后才发现重要的缺陷，而那时我们已经无法再更改了。
As a language, Rust cares a lot about the stability of your code. We want Rust to be a rock-solid foundation you can build on, and if things were constantly changing, that would be impossible. At the same time, if we can’t experiment with new features, we may not find out important flaws until after their release, when we can no longer change things.
我们对这个问题的解决方案是所谓的“稳步前行”（stability without stagnation），我们的指导原则是：你永远不必担心升级到新的稳定版 Rust。每次升级都应该是无痛的，同时也应该带给你新特性、更少的 bug 和更快的编译速度。
Our solution to this problem is what we call “stability without stagnation”, and our guiding principle is this: you should never have to fear upgrading to a new version of stable Rust. Each upgrade should be painless, but should also bring you new features, fewer bugs, and faster compile times.
呜——！发布通道与搭乘列车
Choo, Choo! Release Channels and Riding the Trains
Rust 的开发运行在一个“列车时刻表”上。也就是说，所有的开发都在 Rust 仓库的 main 分支上完成。发布遵循软件发布列车模型，该模型已被 Cisco IOS 和其他软件项目采用。Rust 有三个发布通道：
Rust development operates on a train schedule. That is, all development is done in the main branch of the Rust repository. Releases follow a software release train model, which has been used by Cisco IOS and other software projects. There are three release channels for Rust:
- Nightly
- Beta
- Stable
大多数 Rust 开发者主要使用 stable（稳定）通道，但那些想要尝试实验性新特性的人可能会使用 nightly（每夜）或 beta（测试）通道。
Most Rust developers primarily use the stable channel, but those who want to try out experimental new features may use nightly or beta.
这是一个开发和发布流程如何运作的例子：假设 Rust 团队正在开发 Rust 1.5 版本。该版本发布于 2015 年 12 月，但它能为我们提供真实的版本号。一个新特性被添加到 Rust 中：一个新的提交进入了 main 分支。每天晚上，都会产生一个新的 Rust nightly 版本。每一天都是发布日，这些发布由我们的发布基础设施自动创建。所以随着时间的推移，我们的发布看起来像这样，每晚一次：
Here’s an example of how the development and release process works: let’s assume that the Rust team is working on the release of Rust 1.5. That release happened in December of 2015, but it will provide us with realistic version numbers. A new feature is added to Rust: a new commit lands on the main branch. Each night, a new nightly version of Rust is produced. Every day is a release day, and these releases are created by our release infrastructure automatically. So as time passes, our releases look like this, once a night:
nightly: * - - * - - *
每隔六周，就该准备一个新版本了！Rust 仓库的 beta 分支从 nightly 使用的 main 分支中分出来。现在，有两个发布通道：
Every six weeks, it’s time to prepare a new release! The beta branch of the
Rust repository branches off from the main branch used by nightly. Now,
there are two releases:
nightly: * - - * - - *
|
beta: *
大多数 Rust 用户并不主动使用 beta 版本，但在他们的 CI 系统中针对 beta 进行测试，以帮助 Rust 发现可能的回归。与此同时，每晚仍然有一个 nightly 版本发布：
Most Rust users do not use beta releases actively, but test against beta in their CI system to help Rust discover possible regressions. In the meantime, there’s still a nightly release every night:
nightly: * - - * - - * - - * - - *
|
beta: *
假设发现了一个回归。幸好我们在回归混入稳定版之前有时间测试 beta 版！修复补丁被应用到 main 分支，从而修复 nightly，然后修复补丁被回传（backport）到 beta 分支，并产生一个新的 beta 版本：
Let’s say a regression is found. Good thing we had some time to test the beta
release before the regression snuck into a stable release! The fix is applied
to the main branch, so that nightly is fixed, and then the fix is backported to
the beta branch, and a new release of beta is produced:
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
在第一个 beta 版创建六周后，就该发布稳定版了！stable 分支从 beta 分支产生：
Six weeks after the first beta was created, it’s time for a stable release! The
stable branch is produced from the beta branch:
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
太棒了！Rust 1.5 完成了！然而，我们忘了一件事：因为六周已经过去了，我们还需要下一个 Rust 版本 1.6 的新 beta 版。所以在 stable 从 beta 分离出来后，下一个版本的 beta 又从 nightly 分离出来了：
Hooray! Rust 1.5 is done! However, we’ve forgotten one thing: because the six
weeks have gone by, we also need a new beta of the next version of Rust, 1.6.
So after stable branches off of beta, the next version of beta branches
off of nightly again:
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
这被称为“列车模型”，因为每六周，一个版本就“离开车站”，但在作为稳定版到达之前，它仍需经过 beta 通道的旅程。
This is called the “train model” because every six weeks, a release “leaves the station”, but still has to take a journey through the beta channel before it arrives as a stable release.
Rust 每六周发布一次，像时钟一样准确。如果你知道一个 Rust 版本的发布日期，你就能知道下一个版本的日期：就在六周后。每六周安排一次发布的一个好处是下一班列车很快就会到来。如果一个特性错过了某个特定版本，不必担心：另一个版本很快就会发布！这有助于减轻在接近发布截止日期时匆忙加入可能未完善特性的压力。
Rust releases every six weeks, like clockwork. If you know the date of one Rust release, you can know the date of the next one: it’s six weeks later. A nice aspect of having releases scheduled every six weeks is that the next train is coming soon. If a feature happens to miss a particular release, there’s no need to worry: another one is happening in a short time! This helps reduce pressure to sneak possibly unpolished features in close to the release deadline.
得益于这个过程，你总是可以检出 Rust 的下一个构建版本，并亲自验证升级是否容易：如果 beta 版不像预期的那样工作，你可以向团队报告并让它在下一个稳定版发布之前得到修复！beta 版中的破坏性变动相对少见，但 rustc 仍然是一个软件，bug 确实存在。
Thanks to this process, you can always check out the next build of Rust and
verify for yourself that it’s easy to upgrade to: if a beta release doesn’t
work as expected, you can report it to the team and get it fixed before the
next stable release happens! Breakage in a beta release is relatively rare, but
rustc is still a piece of software, and bugs do exist.
维护时间
Maintenance time
Rust 项目支持最近的稳定版本。当一个新的稳定版本发布时，旧版本就达到了生命周期终点（EOL）。这意味着每个版本都支持六周。
The Rust project supports the most recent stable version. When a new stable version is released, the old version reaches its end of life (EOL). This means each version is supported for six weeks.
不稳定特性
Unstable Features
这种发布模型还有一个特别之处：不稳定特性。Rust 使用一种称为“特性标记”（feature flags）的技术来确定在给定的发布版本中启用哪些特性。如果一个新特性正在积极开发中，它会进入 main 分支，从而进入 nightly 版本，但被置于一个特性标记之后。如果你作为用户希望尝试正在进行中的特性，你可以这样做，但你必须使用 Rust 的 nightly 版本，并在源代码中添加相应的标记以启用它。
There’s one more catch with this release model: unstable features. Rust uses a technique called “feature flags” to determine what features are enabled in a given release. If a new feature is under active development, it lands on the main branch, and therefore, in nightly, but behind a feature flag. If you, as a user, wish to try out the work-in-progress feature, you can, but you must be using a nightly release of Rust and annotate your source code with the appropriate flag to opt in.
如果你使用的是 Rust 的 beta 或 stable 版本，你不能使用任何特性标记。这是让我们在宣布特性永久稳定之前获得实际使用经验的关键。那些希望选择最前沿技术的人可以这样做，而那些想要稳如磐石体验的人可以坚持使用稳定版，并确信他们的代码不会损坏。稳步前行。
If you’re using a beta or stable release of Rust, you can’t use any feature flags. This is the key that allows us to get practical use with new features before we declare them stable forever. Those who wish to opt into the bleeding edge can do so, and those who want a rock-solid experience can stick with stable and know that their code won’t break. Stability without stagnation.
本书仅包含关于稳定特性的信息，因为进行中的特性仍在变化，而且在本手册编写之时和它们在稳定构建中启用之时之间，肯定会有所不同。你可以在网上找到仅限 nightly 特性的文档。
This book only contains information about stable features, as in-progress features are still changing, and surely they’ll be different between when this book was written and when they get enabled in stable builds. You can find documentation for nightly-only features online.
Rustup 和 Rust Nightly 的角色
Rustup and the Role of Rust Nightly
Rustup 使得在全局或每个项目的基础上切换不同的 Rust 发布通道变得容易。默认情况下，你将安装稳定版 Rust。例如，要安装 nightly 版本：
Rustup makes it easy to change between different release channels of Rust, on a global or per-project basis. By default, you’ll have stable Rust installed. To install nightly, for example:
$ rustup toolchain install nightly
你也可以使用 rustup 查看已安装的所有工具链（Rust 的发布版本和相关组件）。这是作者之一的 Windows 电脑上的一个例子：
You can see all of the toolchains (releases of Rust and associated
components) you have installed with rustup as well. Here’s an example on one
of your authors’ Windows computer:
> rustup toolchain list
stable-x86_64-pc-windows-msvc (default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
如你所见，stable 工具链是默认的。大多数 Rust 用户大部分时间使用 stable。你可能希望大部分时间使用 stable，但在特定项目中使用 nightly，因为你关注某个尖端特性。为此，你可以在该项目的目录中使用 rustup override 来设置 rustup 在该目录中应使用的 nightly 工具链：
As you can see, the stable toolchain is the default. Most Rust users use stable
most of the time. You might want to use stable most of the time, but use
nightly on a specific project, because you care about a cutting-edge feature.
To do so, you can use rustup override in that project’s directory to set the
nightly toolchain as the one rustup should use when you’re in that directory:
$ cd ~/projects/needs-nightly
$ rustup override set nightly
现在，每当你在 ~/projects/needs-nightly 内部调用 rustc 或 cargo 时，rustup 都会确保你使用的是 nightly Rust，而不是默认的 stable Rust。当你有许多 Rust 项目时，这非常方便！
Now, every time you call rustc or cargo inside of
~/projects/needs-nightly, rustup will make sure that you are using nightly
Rust, rather than your default of stable Rust. This comes in handy when you
have a lot of Rust projects!
RFC 流程和团队
The RFC Process and Teams
那么你如何了解这些新特性呢？Rust 的开发模型遵循一个“意见征求稿（Request For Comments，简称 RFC）流程”。如果你想对 Rust 进行改进，你可以写一份提案，称为 RFC。
So how do you learn about these new features? Rust’s development model follows a Request For Comments (RFC) process. If you’d like an improvement in Rust, you can write up a proposal, called an RFC.
任何人都可以编写 RFC 来改进 Rust，这些提案由 Rust 团队评审和讨论，该团队由许多主题小组组成。Rust 官方网站上有团队的完整列表，其中包括项目各个领域的团队：语言设计、编译器实现、基础设施、文档等。相应的团队会阅读提案和评论，写下他们自己的一些评论，最终，达成接受或拒绝该特性的共识。
Anyone can write RFCs to improve Rust, and the proposals are reviewed and discussed by the Rust team, which is comprised of many topic subteams. There’s a full list of the teams on Rust’s website, which includes teams for each area of the project: language design, compiler implementation, infrastructure, documentation, and more. The appropriate team reads the proposal and the comments, writes some comments of their own, and eventually, there’s consensus to accept or reject the feature.
如果特性被接受，会在 Rust 仓库中开启一个 issue，然后就有人可以实现它。实现该特性的人很可能不是最初提议该特性的人！当实现准备就绪时，它会进入 main 分支并置于一个特性门控（feature gate）之后，正如我们在 “不稳定特性”部分所讨论的那样。
If the feature is accepted, an issue is opened on the Rust repository, and someone can implement it. The person who implements it very well may not be the person who proposed the feature in the first place! When the implementation is ready, it lands on the main branch behind a feature gate, as we discussed in the “Unstable Features” section.
一段时间后，一旦使用 nightly 版本的 Rust 开发者能够尝试新特性，团队成员将讨论该特性、它在 nightly 上的表现，并决定是否应该让它进入 stable Rust。如果决定推进，特性门控将被移除，该特性现在被认为是稳定的！它将搭乘列车进入一个新的 Rust 稳定版。
After some time, once Rust developers who use nightly releases have been able to try out the new feature, team members will discuss the feature, how it’s worked out on nightly, and decide if it should make it into stable Rust or not. If the decision is to move forward, the feature gate is removed, and the feature is now considered stable! It rides the trains into a new stable release of Rust.