附录 G - Rust 的构建方式与 “Nightly Rust”

本附录是关于 Rust 是如何构建的，以及这会如何影响你作为 Rust 开发者。

稳定但不滞后

作为一门语言，Rust 非常重视代码的稳定性。我们希望 Rust 成为你可以依赖的坚如磐石的基础，如果事物 постоянно 变化，那将是不可能的。与此同时，如果我们不能试验新功能，我们可能无法在发布之前发现重要的缺陷，那时我们就无法再改变任何事情了。

我们针对此问题的解决方案是我们称之为“稳定但不滞后”的方式，我们的指导原则是：你永远不必害怕升级到新版本的 stable Rust。每次升级都应该是轻松的，但也应该为你带来新功能、更少的错误和更快的编译速度。

呜呜！发布渠道与搭乘列车

Rust 的开发以列车时刻表的方式运作。也就是说，所有开发都在 Rust 仓库的 master 分支上完成。发布遵循软件发布列车模型，Cisco IOS 和其他软件项目也使用了这种模型。Rust 有三个发布渠道

  • Nightly
  • Beta
  • Stable

大多数 Rust 开发者主要使用 stable 渠道，但那些想要尝试实验性新功能的人可以使用 nightly 或 beta。

这是一个关于开发和发布过程如何运作的示例：假设 Rust 团队正在致力于发布 Rust 1.5。该版本于 2015 年 12 月发布，但它将为我们提供实际的版本号。一个新功能被添加到 Rust 中：一个新的提交被合并到 master 分支。每晚，都会生成一个新的 nightly 版本的 Rust。每天都是发布日，这些发布由我们的发布基础设施自动创建。因此，随着时间的推移，我们的发布看起来像这样，每晚一次

nightly: * - - * - - *

每六周，就到了准备新版本的时候了！Rust 仓库的 beta 分支从 nightly 使用的 master 分支分叉出来。现在，有两个发布版本

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

大多数 Rust 用户不会积极使用 beta 版本，而是在他们的 CI 系统中针对 beta 进行测试，以帮助 Rust 发现可能的回退错误。与此同时，仍然每晚都有 nightly 版本发布

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

假设发现了一个回退错误。幸好我们有时间在回退错误潜入 stable 版本之前测试 beta 版本！修复程序被应用到 master，以便 nightly 得到修复，然后该修复程序被反向移植到 beta 分支，并生成一个新的 beta 版本

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

在第一个 beta 版本创建六周后，就到了 stable 版本发布的时候了！stable 分支是从 beta 分支创建的

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

万岁！Rust 1.5 完成了！但是，我们忘记了一件事：因为六周已经过去了，我们还需要下一个 Rust 版本 1.6 的新 beta 版本。因此，在 stable 从 beta 分支分叉后，下一个版本的 beta 再次从 nightly 分支分叉出来

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

这被称为“列车模型”，因为每六周，一个版本“离开车站”，但仍然必须经过 beta 渠道的旅程，然后才能作为 stable 版本到达。

Rust 每六周发布一个版本，就像时钟一样准时。如果你知道一个 Rust 版本的日期，你就可以知道下一个版本的日期：那是六周之后。每六周安排一次发布的一个好处是，下一趟列车很快就要来了。如果某个功能恰好错过了某个特定版本，则无需担心：另一个版本很快就会发布！这有助于减轻在发布截止日期临近时偷偷加入可能未完善功能的压力。

由于这个过程，你可以随时查看 Rust 的下一个构建版本，并亲自验证升级是否容易：如果 beta 版本没有按预期工作，你可以向团队报告并在下一个 stable 版本发布之前修复它！beta 版本中的破坏相对罕见，但 rustc 仍然是一个软件，并且确实存在错误。

维护时间

Rust 项目支持最新的 stable 版本。当新的 stable 版本发布时，旧版本将达到其生命周期结束 (EOL)。这意味着每个版本都将获得六周的支持。

不稳定功能

这个发布模型还有一个需要注意的地方：不稳定功能。Rust 使用一种称为“功能标志”的技术来确定在给定版本中启用哪些功能。如果一个新功能正在积极开发中，它会合并到 master，因此也会进入 nightly 版本，但位于功能标志之后。如果你作为用户希望尝试正在开发中的功能，你可以这样做，但你必须使用 nightly 版本的 Rust，并使用适当的标志注释你的源代码以选择启用。

如果你正在使用 beta 或 stable 版本的 Rust，则无法使用任何功能标志。这是使我们能够在永久声明功能稳定之前实际使用新功能的关键。那些希望选择使用最前沿功能的人可以这样做，而那些想要获得坚如磐石体验的人可以坚持使用 stable 版本，并知道他们的代码不会崩溃。稳定但不滞后。

本书仅包含有关 stable 功能的信息，因为正在开发中的功能仍在不断变化，并且肯定会在本书编写时与它们在 stable 构建版本中启用时有所不同。你可以在网上找到仅 nightly 版本功能的相关文档。

Rustup 和 Rust Nightly 的作用

Rustup 可以轻松地在 Rust 的不同发布渠道之间切换，无论是全局还是按项目。默认情况下，你将安装 stable 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

正如你所看到的，stable 工具链是默认的。大多数 Rust 用户在大多数时候都使用 stable 版本。你可能希望在大多数时候使用 stable 版本，但在特定项目上使用 nightly 版本，因为你关心一个前沿功能。为此，你可以在该项目的目录中使用 rustup override 将 nightly 工具链设置为当你位于该目录中时 rustup 应该使用的工具链

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

现在，每次你在 ~/projects/needs-nightly 内部调用 rustc 或 cargo 时，rustup 都会确保你正在使用 nightly Rust，而不是你的默认 stable Rust。当你有大量 Rust 项目时，这会非常方便！

RFC 流程和团队

那么你如何了解这些新功能呢？Rust 的开发模型遵循意见征求 (RFC) 流程。如果你想改进 Rust，你可以撰写一份提案，称为 RFC。

任何人都可以编写 RFC 以改进 Rust，提案由 Rust 团队审查和讨论，Rust 团队由许多主题子团队组成。Rust 网站上有一个完整的团队列表，其中包括项目各个领域的团队：语言设计、编译器实现、基础设施、文档等等。相应的团队阅读提案和评论，撰写他们自己的一些评论，最终达成共识以接受或拒绝该功能。

如果该功能被接受，则会在 Rust 仓库上打开一个 issue，并且有人可以实现它。实现它的人很可能不是最初提出该功能的人！当实现准备就绪时，它会像我们在“不稳定功能”章节中讨论的那样，在功能门控之后合并到 master 分支。

过一段时间后，一旦使用 nightly 版本的 Rust 开发者能够试用新功能，团队成员将讨论该功能，它在 nightly 版本上的运行情况，并决定它是否应该进入 stable Rust。如果决定继续推进，则会移除功能门控，并且该功能现在被认为是 stable 的！它搭乘列车进入 Rust 的新 stable 版本。