x-i18n: generated_at: “2026-03-01T09:16:47Z” model: gemini-3-flash-preview provider: google-gemini-cli source_hash: 87fcdd7cc2df1a8430a9044369e077ac60eda4a0902999542a984dc92a2ddc0c source_path: appendix-07-nightly-rust.md workflow: 16
附录 G - Rust 是如何开发的与 “Nightly Rust” (Appendix G - How Rust is Made and “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)”,我们的指导原则是:你永远不必担心升级到新的稳定版 (stable) 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)
Choo, Choo! Release Channels and Riding the Trains
Rust 的开发遵循“列车进度表 (train schedule)”。也就是说,所有的开发工作都在 Rust 仓库的主分支 (main branch) 上完成。发布过程遵循软件发布列车模型 (software release train model),这一模型已被 Cisco IOS 和其他软件项目所采用。Rust 有三个发布通道 (release channels):
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)
- Nightly
- 测试版 (Beta)
- Beta
- 稳定版 (Stable)
- 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 时:一个新的提交进入了主分支。每天晚上,都会产生一个新的 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) 使用的主分支中分出来。现在,有了两个发布版本:
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 系统中针对测试版进行测试,以帮助 Rust 发现可能的回归 (regressions)。与此同时,每晚仍然会有每夜版 (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: *
假设发现了一个回归。幸好我们在回归潜入稳定版 (stable) 发布之前有时间测试测试版 (beta) 发布!修复补丁会被应用到主分支,这样每夜版 (nightly) 就修复了,然后该修复会被移植回 (backported) 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) 的时候了!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: *
这被称为“列车模型 (train model)”,因为每隔六周,一个发布版本就会“离开车站”,但在作为稳定版发布到达之前,它仍然需要经历测试版 (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) 发布的运行结果不如预期,你可以向团队报告并在下一个稳定版发布之前进行修复!测试版发布中的破坏性变化相对较少,但 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)
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)
Unstable Features
这个发布模型还有一个限制:不稳定特性 (unstable features)。Rust 使用一种称为“功能标识 (feature flags)”的技术来决定在给定的发布版本中启用哪些特性。如果一个新特性正在开发中,它会进入主分支,从而进入每夜版 (nightly),但隐藏在功能标识之后。如果你作为用户希望尝试开发中的特性,你可以这样做,但你必须使用 Rust 每夜版发布,并在源代码中标注相应的标识以选择加入。
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.
本书仅包含关于稳定特性的信息,因为开发中的特性仍在不断变化,在本书编写完成到它们在稳定构建中启用之间,它们肯定会有所不同。你可以在线查找仅限每夜版的特性的文档。
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 每夜版的作用 (Rustup and the Role of Rust Nightly)
Rustup and the Role of Rust Nightly
Rustup 让你能够轻松地在 Rust 的不同发布通道之间进行切换,无论是在全局范围内还是针对单个项目。默认情况下,你将安装稳定版 (stable) 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 安装的所有工具链 (toolchains,即 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
如你所见,稳定版工具链是默认的。大多数 Rust 用户在大部分时间都使用稳定版。你可能希望在大部分时间使用稳定版,但在特定的项目中使用每夜版,因为你关注某个前沿特性。为此,你可以在该项目的目录中使用 rustup override 来设置每夜版工具链,使其成为你在该目录下时 rustup 应使用的工具链:
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 都会确保你使用的是每夜版 Rust,而不是默认的稳定版 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)
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,然后有人可以去实现它。实现它的人很可能并不是最初提出该特性的人!当实现准备就绪时,它会进入主分支,并隐藏在功能门 (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.
一段时间后,一旦使用每夜版发布的 Rust 开发者能够尝试新特性,团队成员将讨论该特性及其在每夜版上的运行效果,并决定是否将其引入稳定版 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.