附录 G - Rust 是如何制作的和 “Nightly Rust”


本附录是关于 Rust 是如何制作的,以及它如何影响作为 Rust 开发人员的你。


稳定而不停滞


作为一种语言,Rust 非常关心代码的稳定性。我们希望 Rust 成为您可以构建的坚如磐石的基础,如果事情不断变化,那将是不可能的。同时,如果我们无法尝试新功能,我们可能要等到它们发布后才能发现重要的缺陷,那时我们无法再改变事情。


我们解决这个问题的方法就是我们所说的 “稳定而不停滞”,我们的指导原则是:你永远不必担心升级到稳定 Rust 的新版本。每次升级都应该是轻松的,但也应该为您带来新功能、更少的错误和更快的编译时间。


咔咔咔!释放频道和乘坐火车


Rust 开发按照火车时间表进行。也就是说,所有开发都是在 Rust 仓库的 master 分支上完成的。版本遵循 Cisco IOS 和其他软件项目使用的软件版本系列模型。Rust 有三个发布渠道


  • 夜间

  • 试用版

  • 稳定


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


下面是开发和发布过程如何运作的一个例子:假设 Rust 团队正在开发 Rust 1.5 的版本。该版本于 2015 年 12 月发布,但它将为我们提供真实的版本号。Rust 中添加了一个新功能:一个新的提交登陆 master 分支。每天晚上,都会生成一个新的 Rust 夜间版本。每一天都是 发布日,这些版本由我们的发布基础设施创建 自然而然。因此,随着时间的推移,我们的版本如下所示,每晚一次:


夜间:*--*--*


每六周,是时候准备新版本了!Rust 仓库的 beta 分支从 nightly 使用的 master 分支出来。现在,有两个版本:

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


大多数 Rust 用户并不积极使用 beta 版本,而是在他们的 CI 系统中针对 beta 进行测试,以帮助 Rust 发现可能的回归。与此同时,每晚仍然有一个 nightly release:

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


假设找到一个回归。好在回归偷偷进入稳定版本之前,我们有一些时间来测试 beta 版本!修复程序将应用于 master,因此 nightly 已修复,然后将修复程序反向移植到 beta 分支,并生成新的 beta 版本:

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


在第一个 beta 版创建六周后,是时候发布稳定版了!这 stable 分支是从 beta 分支生成的:

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


万岁!Rust 1.5 完成了!然而,我们忘记了一件事:因为六周过去了,我们还需要 Rust 下一个版本 1.6 的新测试版。因此,在 stable 分支出 beta 版后,下一个版本的 beta 版再次从 nightly 分支出来:

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


这被称为 “火车模型”,因为每六周,一个版本“离开车站”,但在它作为稳定版本到达之前,仍然必须通过 beta 通道。


Rust 每六周发布一次,就像发条一样。如果你知道一个 Rust 版本的发布日期,你就可以知道下一个版本的日期:它是六周后。每六周安排一次发布的一个好处是下一班火车很快就会到来。如果某个功能碰巧错过了某个特定版本,则无需担心:另一个功能将在短时间内发布!这有助于减轻在接近发布截止日期时偷偷使用可能未完善的功能的压力。


多亏了这个过程,你可以随时查看 Rust 的下一个版本和 亲自验证它是否易于升级到:如果 beta 版本没有 按预期工作,您可以向团队报告并在 下一个稳定版本发布!测试版中的损坏相对较少,但 rustc 仍然是一个软件,确实存在 bug。


维护时间


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


不稳定的特性


此发布模型还有一个问题:不稳定的功能。Rust 使用 称为“功能标志”的技术来确定在 给定的发布。如果新功能正在积极开发中,则它会登陆 master,因此,在 nightly 中,但在功能标志后面。如果您作为用户希望尝试正在进行的功能,您可以尝试,但您必须使用 Rust 的夜间版本,并使用适当的标志注释您的源代码才能选择加入。


如果您使用的是 Rust 的 beta 版或稳定版,则不能使用任何功能标志。这是让我们在宣布新功能永远稳定之前获得新功能实际使用的关键。那些希望选择进入前沿的人可以这样做,那些想要坚如磐石的体验的人可以坚持使用 stable,并且知道他们的代码不会中断。稳定而不停滞。


本书仅包含有关稳定功能的信息,因为开发中的功能仍在变化,并且它们肯定会在编写本书时和在稳定版本中启用时有所不同。您可以在线查找仅限 nightly 功能的文档。


Rustup 和 Rust Nightly 的角色


Rustup 可以轻松地在全局或每个项目的不同 Rust 发布频道之间进行切换。默认情况下,您将安装稳定的 Rust。要每晚安装,例如:

$ 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 用户大部分时间都使用 stable。你可能想在大部分时间使用 stable,但在特定项目上使用 nightly,因为你关心的是尖端功能。为此,你可以在该项目的目录中使用 rustup override 将 nightly 工具链设置为你在该目录中时应该使用的 rustup 工具链:

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


现在,每次你在 ~/projects/needs-nightly,rustup 将确保你使用的是 nightly Rust,而不是默认的稳定 Rust。 当你有很多 Rust 项目时,这会派上用场!


RFC 流程和团队


那么,您如何了解这些新功能呢?Rust 的开发模型遵循 Request For Comments (RFC) 流程。如果你想改进 Rust,你可以写一个提案,叫做 RFC。


任何人都可以编写 RFC 来改进 Rust,这些提案由 Rust 团队审查和讨论,该团队由许多主题子团队组成。Rust 的 网站上,其中包括项目每个领域的团队:语言设计、编译器实现、基础设施、文档等。适当的团队阅读提案和评论,写下一些自己的评论,最终达成接受或拒绝该功能的共识。


如果该功能被接受,则会在 Rust 存储库中打开一个 issue,并且有人可以实现它。实现得非常好的人,可能不是当初提出这个功能的人!当实现准备就绪时,它会落在特性门控后面的 master 分支上,正如我们在 “不稳定特性” 一节中所讨论的那样。


一段时间后,一旦使用 nightly 版本的的 Rust 开发人员能够试用新功能,团队成员将讨论该功能,它在 nightly 上是如何工作的,并决定它是否应该成为稳定的 Rust。如果决定向前发展,则 Feature Gate 将被移除,并且该功能现在被认为是稳定的!它把火车带到了一个新的 Rust 稳定版本中。