G - Rust 是如何开发的与 “Nightly Rust” - Rust 程序设计语言中文版

附录 G：Rust 是如何开发的与 “Nightly Rust”

本附录介绍 Rust 是如何开发的以及这如何影响作为 Rust 开发者的你。

稳定而不停滞

作为一个语言，Rust 非常关心代码的稳定性。我们希望 Rust 成为你代码的坚实基础，假如持续地有东西在变，这个希望就实现不了。与此同时，如果不能试验新功能的话，在发布之前我们又无法发现其中重大的缺陷，而一旦发布便再也没有修改的机会了。

对于这个问题我们的解决方案被称为 “稳定而不停滞”（“stability without stagnation”），其指导性原则是：无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的，并带来新功能，更少的 bug 和更快的编译速度。

发布通道和乘坐火车

Rust 开发按照火车时刻表（train schedule）运行。也就是说，所有的开发工作都是在 Rust 仓库的 master 分支上完成的。Rust 发布采用火车模型发布模式（software release train model），其被用于思科 IOS 和其它软件项目。Rust 有三个发布通道（release channel）：

Nightly（开发版）
Beta（预览版）
Stable（稳定版）

大部分 Rust 开发者主要采用稳定版通道，不过希望实验新功能的开发者可能会使用开发版或预览版。

下面是一个开发和发布过程如何运转的示例：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，但它将为我们提供真实的版本号。Rust 新增了一项功能：一个新的提交到 master 分支。每天晚上，会产生一个新的开发版（nightly 版）Rust。每天都是发布日，而这些发布由发布基础设施自动创建。所以随着时间推移，发布轨迹看起来像这样，每晚一次：

nightly: * - - * - - *

每 6 周，是时候准备一个新版本了！Rust 仓库的 beta 分支会从开发版的 master 分支分出来。现在，有了两个发布版本：

nightly: * - - * - - *
                     |
beta:                *

大部分 Rust 用户不会主动使用 beta 发布版本，不过在 CI 系统（持续集成系统）中对 beta 版本进行测试能帮助 Rust 发现可能的回归缺陷（regression）。同时，每晚仍产生开发发布版：

nightly: * - - * - - * - - * - - *
                     |
beta:                *

比如我们发现了一个回归缺陷。好消息是在这些缺陷流入稳定发布之前还有一些时间来测试 beta 版本！修复在 master 分支进行，从而 nightly 版本得到了修复，接着将这些修复向后移植到 beta 分支，一个新的 beta 发布就产生了：

nightly: * - - * - - * - - * - - * - - *
                     |
beta:                * - - - - - - - - *

在创建第一个 beta 版 6 周后，是时候发布稳定版本了！stable 分支从 beta 分支生成：

nightly: * - - * - - * - - * - - * - - * - * - *
                     |
beta:                * - - - - - - - - *
                                       |
stable:                                *

好极了！Rust 1.5 发布了！然而，我们忘了些东西：因为 6 周过去了，我们还需发布下一个 Rust 1.6 的全新 beta 版本。所以从 beta 生成 stable 分支后，下一版的 beta 分支也再次从 nightly 生成：

nightly: * - - * - - * - - * - - * - - * - * - *
                     |                         |
beta:                * - - - - - - - - *       *
                                       |
stable:                                *

这被称为“火车模式”（train model），因为每 6 周，一个版本“离开车站”，不过从 beta 通道到达稳定通道还有一段旅程。

Rust 每 6 周发布一次，就像发条一样。如果你知道了某个 Rust 版本的发布日期，就可以知道下个版本的日期：6 周后。每 6 周发布一版的一个好处是下一班火车即将到来。如果一个功能在特定版本中错过了也无需担心：另一个版本很快就会到来！这有助于减少在发布截止日期前匆忙加入可能未完善的功能的压力。

多亏了这个过程，你可以随时切换到下一版本的 Rust 并验证它是否易于升级：如果 beta 版不能如期工作，你可以向 Rust 团队报告并在发布下一个稳定版之前得到修复！beta 版造成的破坏是非常少见的，但 rustc 也是一个软件，仍可能存在 bug。

维护时间

Rust项目支持最新的稳定版本。当一个新的稳定版本发布时，旧版本就达到了其生命周期（EOL）。这意味着每个版本都支持六周。

这个发布模型中另一个值得注意的地方：不稳定功能（unstable features）。Rust 使用一个被称为 “功能标记”（“feature flags”）的技术来确定给定版本的某个功能是否启用。如果新功能正在积极地开发中，其提交到了 master，因此会出现在 nightly 版中，不过会位于一个 功能标记 之后。作为用户，如果你希望尝试这个正在开发的功能，则可以在源码中使用合适的标记来开启，不过必须使用 nightly 版。

如果使用的是 beta 或稳定版 Rust，则不能使用任何功能标记。这是在新功能被宣布为永久稳定之前获得实用价值的关键。这既满足了希望使用最尖端技术的同学，那些坚持稳定版的同学也知道其代码不会被破坏。这就是无停滞稳定。

本书只包含稳定的功能，因为还在开发中的功能仍可能改变，当其进入稳定版时肯定会与编写本书的时候有所不同。你可以在网上获取 nightly 版的文档。

Rustup 和 Rust Nightly 的职责

Rustup 使得改变不同发布通道的 Rust 更为简单，其在全局或分项目的层次工作。其默认会安装稳定版 Rust。例如为了安装 nightly：

$ rustup install nightly

你会发现 rustup 也安装了所有的工具链（toolchains， 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 来设置当前目录 rustup 使用 nightly 工具链：

$ cd ~/projects/needs-nightly
$ rustup override set nightly

现在，每次在 ~/projects/needs-nightly 调用 rustc 或 cargo，rustup 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益！

RFC 过程和团队

那么你如何了解这些新功能呢？Rust 开发模式遵循一个 Request For Comments (RFC，征求评审) 过程。如果你希望改进 Rust，可以编写一个提议，也就是 RFC。

任何人都可以编写 RFC 来改进 Rust，同时这些 RFC 会被 Rust 团队评审和讨论，他们由很多不同分工的子团队组成。这里是 Rust 官网上所有团队的总列表，其包含了项目中每个领域的团队：语言设计、编译器实现、基础设施、文档等。各个团队会阅读相应的提议和评论，编写回复，并最终达成接受或回绝功能的一致。

如果功能被接受了，在 Rust 仓库会打开一个 issue，人们就可以实现它。实现功能的人当然可能不是最初提议功能的人！当实现完成后，其会合并到 master 分支并位于一个功能开关（feature gate）之后，正如 “不稳定功能” 章节所讨论的。

在稍后的某个时间，一旦使用 nightly 版的 Rust 团队能够尝试这个功能了，团队成员会讨论这个功能，它如何在 nightly 中工作，并决定是否应该进入稳定版。如果决定继续推进，功能开关会移除，然后这个功能就被认为是稳定的了！乘着“发布的列车”，最终在新的稳定版 Rust 中出现。

Rust 程序设计语言 中文版