附录 G - Rust 的制作过程和“Nightly Rust”
这个附录是关于 Rust 是如何被创建的,以及这如何影响你作为 Rust 开发者。
稳定而不停滞
作为一种语言,Rust 非常重视代码的稳定性。我们希望 Rust 能成为你可以构建的坚如磐石的基础,如果事情不断变化,这是不可能的。同时,如果我们不能尝试新功能,我们可能无法在发布后发现重要的缺陷,那时我们再也无法改变任何事情。
我们的解决方案是所谓的“稳定而不停滞”,
我们的指导原则是:
您永远不必担心升级到新的稳定版Rust。
每次升级都应该是无痛的,但也应该为您带来新功能、更少的错误和更快的编译时间。
嘟,嘟!发布渠道和乘坐火车
Rust 开发遵循 列车时间表。也就是说,所有开发都在 Rust 仓库的 master
分支上进行。发布遵循软件发布列车模型,该模型已被 Cisco IOS 和其他软件项目使用。Rust 有三个 发布渠道:
- 好的,我明白了。请提供您需要翻译的源文本。
- Beta,直接输出翻译内容,不要添加任何额外的文本。绝对不要添加原始翻译内容中没有的符号或标签。记住,保留所有HTML标签和属性,只翻译内容!
- 稳定的,直接输出翻译内容,不添加任何额外的文本。绝对不要添加原文中没有的符号或标签。记住,保留所有HTML标签和属性,只翻译内容!
大多数 Rust 开发者主要使用稳定通道,但那些想要尝试实验性新功能的人可能会使用 nightly 或 beta。
这是一个开发和发布过程的例子:假设 Rust 团队正在开发 Rust 1.5 的发布。该发布发生在 2015 年 12 月,但它将为我们提供现实的版本号。Rust 添加了一个新功能:master
分支上有一个新的提交。每个晚上,都会生成一个新的 Rust 夜度版本。每天都是发布日,这些发布是由我们的发布基础设施自动创建的。因此,随着时间的推移,我们的发布情况如下,每晚一次:
nightly: * - - * - - *
每六周,就到了准备新版本的时候了!Rust 仓库的 beta
分支从用于 nightly 的 master
分支分出。现在,有两个版本:
nightly: * - - * - - *
|
beta: *
大多数 Rust 用户不会积极使用 beta 版本,但会在他们的 CI 系统中测试 beta 版本,以帮助 Rust 发现可能的回归。与此同时,每天晚上仍然会有一次 nightly 版本的发布:
nightly: * - - * - - * - - * - - *
|
beta: *
假设发现了一个回归。还好我们有时间在回归潜入稳定版之前测试了测试版!修复程序已应用于master
,因此夜间构建已修复,然后修复程序被回溯到beta
分支,并生成了新的测试版发布:
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
在首个测试版创建六周后,是时候发布稳定版了!stable
分支是从 beta
分支生成的:
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
好极了!Rust 1.5 完成了!但是,我们忘记了一件事:因为六周已经过去了,我们也需要 下一个 版本的 Rust,1.6 的新测试版。所以在 stable
从 beta
分支出来后,beta
的下一个版本再次从 nightly
分支出来:
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
这被称为“列车模型”,因为每隔六周,一个版本就会“离开车站”,但仍然需要通过beta渠道的旅程,才能作为稳定版发布。
Rust 每六周发布一次,像时钟一样准时。如果你知道一个 Rust 发布的日期,你就可以知道下一个发布的日期:它在六周后。每六周发布一次的一个好处是,下一班列车很快就会到来。如果一个特性恰好错过了某个特定的发布,无需担心:很快就会有另一个发布!这有助于减少在接近发布截止日期时匆忙加入可能未完成的特性的压力。
通过这个过程,您可以随时检查 Rust 的下一个构建版本并亲自验证升级是否简单:如果 beta 版本没有按预期工作,您可以在下一个稳定版本发布之前向团队报告并得到修复!beta 版本中的问题相对较少,但 rustc
仍然是一个软件,确实存在 bug。
维护时间
Rust 项目支持最新的稳定版本。当发布新的稳定版本时,旧版本将达到其生命周期结束(EOL)。这意味着每个版本将获得六周的支持。
不稳定特性
还有这个发布模型的一个陷阱:不稳定的特性。Rust 使用一种称为“特性标志”的技术来确定在给定版本中启用哪些特性。如果一个新特性正在积极开发中,它会被合并到master
,因此,也在 nightly 中,但位于一个特性标志之后。如果你,作为用户,希望尝试这个正在进行中的特性,你可以这样做,但你必须使用 Rust 的 nightly 版本,并在源代码中使用适当的标志来选择加入。
如果您使用的是 Rust 的 beta 或稳定版本,您不能使用任何功能标志。这是使我们能够在宣布新功能永久稳定之前就获得实际使用的关键。那些希望尝试最新功能的人可以选择加入,而那些希望获得坚如磐石体验的人可以坚持使用稳定版本,并知道他们的代码不会出问题。稳定而不停滞。
这本书只包含关于稳定功能的信息,因为正在进行中的功能仍在变化,当这本书编写时和它们在稳定版本中启用时肯定会有所不同。您可以在网上找到仅限于夜间构建的功能的文档。
Rustup 和 Rust Nightly 的角色
Rustup 使得在不同的 Rust 发布渠道之间切换变得容易,无论是全局还是按项目基础。默认情况下,您将安装稳定版的 Rust。例如,要安装夜间版:rustup install 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 用户大多数时间使用稳定版本。您可能大多数时间也想使用稳定版本,但在某个特定项目中使用夜间版,因为您关心一个前沿特性。为此,您可以在该项目的目录中使用 rustup override
将夜间工具链设置为 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 仓库中开启一个 issue,然后有人可以实现它。实现它的人可能并不是最初提出该特性的人!当实现准备就绪时,它将在特性门后登陆到 master
分支,正如我们在 “不稳定特性” 部分讨论的那样。
一段时间后,一旦使用夜间版本的 Rust 开发者能够尝试新功能,团队成员将讨论该功能,以及它在夜间版本中的表现,并决定是否将其纳入稳定的 Rust 中。如果决定继续推进,功能门将被移除,该功能现在被视为稳定!它将随着火车进入 Rust 的新稳定版本。