附录 G - Rust 的构建方式以及 “Nightly Rust”
本附录将介绍 Rust 是如何构建的,以及这如何影响您作为 Rust 开发人员。
稳定而不会停滞
作为一种语言,Rust 非常关心代码的稳定性。我们希望 Rust 成为您可以构建的坚实基础,如果事情不断变化,那将是不可能的。与此同时,如果我们不能尝试新功能,我们可能在发布后才会发现重要的缺陷,而那时我们已经无法再改变了。
我们解决这个问题的方法是我们所谓的“稳定而不会停滞”,我们的指导原则是:您永远不必担心升级到新版本的稳定 Rust。每次升级都应该是无痛的,但也应该为您带来新功能、更少的错误和更快的编译时间。
呜呜!发布通道和乘坐列车
Rust 的开发按照列车时刻表运行。也就是说,所有开发都在 Rust 存储库的 master
分支上进行。发布遵循软件发布列车模型,该模型已被 Cisco IOS 和其他软件项目使用。Rust 有三个发布通道
- Nightly(每日构建版)
- Beta(测试版)
- Stable(稳定版)
大多数 Rust 开发人员主要使用稳定通道,但那些想尝试实验性新功能的人可以使用 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: *
假设发现了一个回归。幸运的是,我们在回归潜入稳定版本之前有一些时间来测试 beta 版本!修复程序应用于 master
,以便 nightly 被修复,然后该修复程序被反向移植到 beta
分支,并生成一个新的 beta 版本
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
在第一个 beta 版本创建六周后,是时候发布稳定版本了! stable
分支由 beta
分支生成
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
万岁!Rust 1.5 完成了!但是,我们忘记了一件事:因为已经过去了六周,我们还需要一个下一个版本的 Rust 的新 beta 版本,即 1.6。因此,在 stable
从 beta
分叉后,下一个版本的 beta
再次从 nightly
分叉
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
这被称为“列车模型”,因为每六周,一个版本“离开车站”,但仍然必须经历 beta 通道才能作为稳定版本到达。
Rust 每六周发布一次,就像发条一样。如果您知道一个 Rust 版本的日期,您就可以知道下一个版本的日期:那是六周之后。每六周安排一次发布的一个好处是,下一班列车很快就会到来。如果某个功能恰好错过了特定的版本,则无需担心:很快就会有另一个版本!这有助于减少在接近发布截止日期时偷偷加入可能未完善的功能的压力。
感谢这个过程,您可以随时查看 Rust 的下一个构建版本,并亲自验证它是否易于升级:如果 beta 版本没有按预期工作,您可以向团队报告并使其在下一个稳定版本发布之前得到修复!beta 版本中的破坏相对罕见,但 rustc
仍然是一个软件,并且确实存在错误。
维护时间
Rust 项目支持最新的稳定版本。当发布新的稳定版本时,旧版本将到达其生命周期结束 (EOL)。这意味着每个版本都支持六周。
不稳定功能
此发布模型还有另一个问题:不稳定功能。Rust 使用一种称为“功能标志”的技术来确定在给定版本中启用了哪些功能。如果一个新功能正在积极开发中,它将登陆 master
,因此,登陆 nightly,但在功能标志后面。如果您作为用户希望尝试正在进行中的功能,您可以,但您必须使用 nightly 版本的 Rust 并使用适当的标志注释您的源代码以选择加入。
如果您使用的是 beta 或稳定版本的 Rust,则不能使用任何功能标志。这是允许我们在声明它们永久稳定之前实际使用新功能的关键。那些希望选择加入前沿技术的人可以这样做,而那些想要获得坚如磐石的体验的人可以坚持使用稳定版本,并且知道他们的代码不会中断。稳定而不会停滞。
本书仅包含有关稳定功能的信息,因为正在进行中的功能仍在变化,并且在本书编写时和它们在稳定版本中启用时肯定会有所不同。您可以在网上找到仅限 nightly 功能的文档。
Rustup 和 Rust Nightly 的作用
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,而不是默认的 stable Rust。当您有许多 Rust 项目时,这会派上用场!
RFC 流程和团队
那么您如何了解这些新功能呢?Rust 的开发模型遵循请求意见 (RFC) 流程。如果您希望 Rust 进行改进,您可以编写一份提案,称为 RFC。
任何人都可以编写 RFC 来改进 Rust,提案由 Rust 团队审查和讨论,该团队由许多主题子团队组成。在 Rust 的网站上有一个完整的团队列表,其中包括项目每个领域的团队:语言设计、编译器实现、基础设施、文档等等。适当的团队会阅读提案和评论,编写他们自己的一些评论,最终达成共识以接受或拒绝该功能。
如果该功能被接受,则会在 Rust 存储库上打开一个问题,并且有人可以实现它。实现它的人很可能不是最初提出该功能的人!当实现准备就绪时,它会像我们在“不稳定功能”中讨论的那样,在功能门后面登陆 master
分支部分。
一段时间后,一旦使用 nightly 版本的 Rust 开发人员能够尝试新功能,团队成员将讨论该功能、它在 nightly 上的效果,并决定是否应将其纳入稳定的 Rust。如果决定继续前进,则删除功能门,并且该功能现在被认为是稳定的!它乘坐列车进入 Rust 的新稳定版本。