附录 G：Rust 的开发方式与“Nightly Rust”
本附录介绍 Rust 的开发方式，以及这对 Rust 开发者意味着什么。
稳定而不僵化
作为一门语言，Rust 非常重视代码的稳定性。我们希望 Rust 成为可靠坚实的基础，让你可以放心构建软件；如果一切都在不断变化，这就无从谈起。与此同时，如果我们无法试验新功能，就可能要等到功能发布后才发现重要缺陷，而那时已经无法再修改。
我们将这个问题的解决方案称为“稳定而不僵化”，其指导原则是：升级到新版稳定版 Rust 时，你不应该感到担忧。每次升级都应该轻松无痛，同时带来新功能、更少的错误和更快的编译速度。
鸣笛开车！发布渠道与版本列车
Rust 开发采用列车时刻表模式：所有开发都在 Rust 仓库的主分支上进行。Rust 的发布遵循软件发布列车模型，Cisco IOS 和其他软件项目也采用过这种模型。Rust 有三个发布渠道：
- Nightly（夜间版）
- Beta（测试版）
- Stable（稳定版）
大多数 Rust 开发者主要使用稳定版渠道；想尝试实验性新功能的开发者则可以使用 nightly 或 beta。
下面举例说明开发和发布流程。假设 Rust 团队正在准备 Rust 1.5 的发布。这个版本于 2015 年 12 月发布，我们借此使用更贴近实际的版本号。现在，Rust 加入了一项新功能：一个新的提交合入主分支。每晚都会构建一个新的 nightly 版本。每天都是发布日，这些版本由发布基础设施自动生成。随着时间推移，每晚的发布过程如下所示：
nightly: * - - * - - *
每隔六周，就要准备一次新版本发布！Rust 仓库的 beta 分支会从 nightly 使用的主分支切出。此时便有了两个发布渠道：
nightly: * - - * - - *
|
beta: *
大多数 Rust 用户不会主动使用 beta 版本，但会在 CI 系统中针对 beta 进行测试，帮助 Rust 发现可能的回归问题。与此同时，nightly 仍会每晚发布：
nightly: * - - * - - * - - * - - *
|
beta: *
假设发现了一个回归问题。幸好我们有时间在它进入稳定版之前测试 beta 版本！修复会先应用到主分支，从而修复 nightly；随后再将修复向后移植到 beta 分支，并发布新的 beta 版本：
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
第一个 beta 版本创建六周后，就到了发布稳定版的时候！stable 分支由 beta 分支生成：
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
太好了！Rust 1.5 发布完成！不过还要记住一件事：六周已经过去，我们还需要为 Rust 的下一个版本 1.6 创建新的 beta 版本。因此，在 stable 从 beta 切出后，下一版 beta 也会再次从 nightly 切出：
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
这称为“列车模型”，因为每隔六周就有一个版本“驶离车站”，但它仍需经过 beta 渠道，最终才能作为稳定版抵达。
Rust 像钟表一样每六周发布一次。如果你知道某个 Rust 版本的发布日期，就能知道下一个版本的日期：六周之后。按六周计划发布的一个好处是，下一班列车很快就会到来。如果某项功能没赶上某次发布，也不必担心：下一次发布很快就会到来！这也减轻了在发布截止日期临近时仓促塞入尚未打磨完善功能的压力。
得益于这一流程，你可以随时试用 Rust 的下一个构建版本，并亲自确认升级是否容易：如果 beta 版本表现不符合预期，你可以向团队报告，并在下一个稳定版发布前修复问题！beta 版本出现问题的情况相对少见，但 rustc 仍然是软件，难免会有错误。
维护周期
Rust 项目只支持最新的稳定版本。新稳定版发布后，旧版本便达到生命周期终止（EOL）。这意味着每个版本的支持周期为六周。
不稳定功能
这种发布模式还有一个需要注意的地方：不稳定功能。Rust 使用一种称为“功能标志”的技术，来决定某个版本启用哪些功能。如果一项新功能正在积极开发，它会合入主分支，因此也会进入 nightly，但会由一个功能标志控制。如果你想尝试尚在开发中的功能，可以使用 Rust 的 nightly 版本，并在源代码中添加相应标志以选择启用。
如果你使用的是 Rust beta 或稳定版，就不能使用任何功能标志。这使我们能够在正式宣布新功能永久稳定之前，先在实际场景中使用和检验它们。想要尝鲜的用户可以选择使用最新的实验功能；希望获得坚实可靠体验的用户则可以继续使用稳定版，并确信代码不会因此损坏。这就是稳定而不僵化。
本书只介绍稳定功能，因为仍在开发中的功能会不断变化；从本书编写到这些功能进入稳定版之间，它们很可能还会发生变化。你可以在网上查阅仅适用于 nightly 的功能文档。
rustup 与 Nightly Rust 的作用
rustup 可以轻松切换 Rust 的不同发布渠道，并支持全局设置或按项目设置。默认情况下，你会安装稳定版 Rust。例如，安装 nightly：
$ rustup toolchain install nightly
你也可以使用 rustup 查看已安装的所有工具链（Rust 发行版及其关联组件）。下面是其中一位作者在 Windows 电脑上的示例：
> rustup toolchain list
stable-x86_64-pc-windows-msvc (default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
如你所见，稳定版工具链是默认工具链。大多数 Rust 用户通常使用稳定版。你可能也希望大部分时间使用稳定版，但在某个特定项目中使用 nightly，以便尝试前沿功能。为此，可以在该项目目录中使用 rustup override，将 nightly 工具链设为 rustup 在此目录中应使用的工具链：
$ cd ~/projects/needs-nightly
$ rustup override set nightly
现在，每当你在 ~/projects/needs-nightly 中调用 rustc 或 cargo 时，rustup 都会确保使用 nightly Rust，而不是默认的稳定版。如果你有很多 Rust 项目，这会非常方便！
RFC 流程与团队
那么，如何了解这些新功能呢？Rust 的开发模式遵循征求意见（RFC）流程。如果你希望改进 Rust，可以撰写一份称为 RFC 的提案。
任何人都可以撰写 RFC 来改进 Rust。提案由 Rust 团队审查和讨论，该团队由多个主题小组组成。Rust 官网列出了所有团队，包括负责项目各领域的团队：语言设计、编译器实现、基础设施、文档等。相关团队会阅读提案及其评论、撰写自己的意见，最终就接受还是拒绝该功能达成共识。
如果提案被接受，Rust 仓库中会创建一个 issue，之后就有人可以实现该功能。实际实现者很可能并不是最初提出该功能的人！实现准备就绪后，它会像前面“不稳定功能”一节所述那样，在功能门控下合入主分支。
一段时间后，使用 nightly 版本的 Rust 开发者已经试用过新功能，团队成员便会讨论该功能及其在 nightly 中的表现，并决定是否将它纳入稳定版 Rust。如果决定继续推进，就会移除功能门控，该功能也就正式成为稳定功能！随后，它会搭上版本列车进入新的 Rust 稳定版。