@ -1,7 +1,6 @@
## 附录 G: Rust 是如何开发的与 “Nightly Rust”
## 附录 G: Rust 是如何开发的与 “Nightly Rust”
<!-- https://github.com/rust - lang/book/blob/main/src/appendix - 07 - nightly - rust.md -->
[appendix-07-nightly-rust.md ](https://github.com/rust-lang/book/blob/af415fc6c8a6823dfb4595074f27d5a3e9e2fe49/src/appendix-07-nightly-rust.md )
<!-- commit 3a30e4c1fbe641afc066b3af9eb01dcdf5ed8b24 -->
本附录介绍 Rust 是如何开发的以及这对你作为 Rust 开发者的影响。
本附录介绍 Rust 是如何开发的以及这对你作为 Rust 开发者的影响。
@ -13,7 +12,7 @@
### Choo, Choo! 发布通道和发布时刻表( Riding the Trains)
### Choo, Choo! 发布通道和发布时刻表( Riding the Trains)
Rust 开发运行于一个**发布时刻表**( _train schedule_) 之上。也就是说, 所有的开发工作都位于 Rust 仓库的 `master` 分支。发布采用 software release train 模型,其被用于思科 IOS 等其它软件项目 。Rust 有三个**发布通道**( _release channel_) :
Rust 开发运行于一个**发布时刻表**( _train schedule_) 之上。也就是说, 所有的开发工作都发生在 Rust 仓库的主分支上。发布采用 software release train 模型,它曾被 Cisco IOS 及其他软件项目采用 。Rust 有三个**发布通道**( _release channel_) :
- Nightly
- Nightly
- Beta
- Beta
@ -21,13 +20,13 @@ Rust 开发运行于一个**发布时刻表**( _train schedule_) 之上。也
大部分 Rust 开发者主要采用稳定版通道,不过希望实验新功能的开发者可能会使用 nightly 或 beta 版。
大部分 Rust 开发者主要采用稳定版通道,不过希望实验新功能的开发者可能会使用 nightly 或 beta 版。
如下是一个开发和发布过程如何运转的例子:假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月, 不过这里只是为了提供一个真实的版本。Rust 新增了一项功能:一个 `master` 分支的 新提交。每天晚上,会产生一个新的 nightly 版本。每天都是发布版本的 日子 ,而这些发布由发布基础设施自动完成。所以随着时间推移,发布轨迹看起来像这样,版本每晚一发:
如下是一个开发和发布过程如何运转的例子:假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月,不过这里只是为了提供一个真实的版本号 。Rust 新增了一项功能:一个新提交进入了主分支 。每天晚上,都 会产生一个新的 nightly 版本。每天都是发布日,而这些发布由发布基础设施自动完成。所以随着时间推移,发布轨迹看起来像这样,版本每晚一发:
```text
```text
nightly: * - - * - - *
nightly: * - - * - - *
```
```
每六周时间, 是准备发布新版本的时候了! Rust 仓库的 `beta` 分支会从用于 nightly 的 `master` 分支产生 。现在,有了两个发布渠道:
每六周时间, 是准备发布新版本的时候了! Rust 仓库的 `beta` 分支会从 nightly 所使用的主分支分出 。现在,有了两个发布渠道:
```text
```text
nightly: * - - * - - *
nightly: * - - * - - *
@ -43,7 +42,7 @@ nightly: * - - * - - * - - * - - *
beta: *
beta: *
```
```
比如我们发现了一个回归缺陷。好消息是在这些回归缺陷流入稳定发布之前还有一些时间来测试 beta 版本! fix 被合并到 `master` ,为此 nightly 版本得到了修复,接着这些 fix 将 backport 到 `beta` 分支,一个 新的 beta 发布就产生了:
比如我们发现了一个回归缺陷。好消息是,在这些回归缺陷流入稳定发布之前,我们还有一些时间来测试 beta 版本!修复会先应用到主分支,因此 nightly 版本先得到修复;然后再把修复回移植到 `beta` 分支,于是 新的 beta 发布就产生了:
```text
```text
nightly: * - - * - - * - - * - - * - - *
nightly: * - - * - - * - - * - - * - - *
@ -83,7 +82,7 @@ Rust 项目仅对最近的稳定版本提供支持。当发布新稳定版本时
### 不稳定功能
### 不稳定功能
这个发布模型中另一个值得注意的地方: 不稳定功能( unstable features) 。Rust 使用一个被称为 “功能标记”( “feature flags”) 的技术来确定给定版本的某个功能是否启用。如果新功能正在积极地开发中, 其提交到了 `master` ,因此会出现在 nightly 版中,不过会位于一个 ** 功能标记** 之后。作为用户,如果你希望尝试这个正在开发的功能,必须使用 nightly 版并在源码中使用合适的标记来开启 。
这个发布模型中另一个值得注意的地方: 不稳定功能( unstable features) 。Rust 使用一种叫做 **feature flags** 的技术来决定某个发布中启用了哪些功能。如果一个新功能仍在积极开发中,它会进入主分支,因此也会出现在 nightly 版本里,但会被放在某个 ** 功能标记** 之后。作为用户,如果你想尝试这个仍在开发中的功能,可以这么做,但你必须使用 nightly 版 Rust, 并在源码中添加相应的标记来显式启用它 。
如果使用的是 beta 或稳定版 Rust, 则不能使用任何功能标记。这是在新功能被宣布为永久稳定之前让大家提前实际使用它们的关键。这既满足了希望使用最尖端技术的同学, 那些坚持稳定版的同学也知道其代码不会被破坏。这就是无停滞稳定。
如果使用的是 beta 或稳定版 Rust, 则不能使用任何功能标记。这是在新功能被宣布为永久稳定之前让大家提前实际使用它们的关键。这既满足了希望使用最尖端技术的同学, 那些坚持稳定版的同学也知道其代码不会被破坏。这就是无停滞稳定。
@ -91,13 +90,13 @@ Rust 项目仅对最近的稳定版本提供支持。当发布新稳定版本时
### Rustup 和 Rust Nightly 的职责
### Rustup 和 Rust Nightly 的职责
Rustup 使得改变不同发布通道的 Rust 更为简单,其在全局或分项目的层次工作。其默认会安装稳定版 Rust。例如, 为了 安装 nightly:
Rustup 使得在不同 Rust 发布通道之间切换变得很容易,无论是全局还是按项目都可以。默认情况下,你安装的是稳定版 Rust。例如, 要 安装 nightly:
```console
```console
$ rustup toolchain install nightly
$ rustup toolchain install nightly
```
```
你会发现 `rustup` 也安装了所有的**工具链**( _toolchains_, Rust 和其相关组件)。如下是一位作者的 Windows 计算机 上的例子:
你也可以用 `rustup` 查看已经安装的所有**工具链**( _toolchains_, 也就是 Rust 发布版本及其相关组件)。下面是一位作者的 Windows 电脑 上的例子:
```powershell
```powershell
> rustup toolchain list
> rustup toolchain list
@ -121,6 +120,6 @@ $ rustup override set nightly
任何人都可以编写 RFC 来改进 Rust, 同时这些 RFC 会被 Rust 团队评审和讨论,他们由很多不同分工的子团队组成。这里是 [Rust 官网上 ](https://www.rust-lang.org/governance ) 所有团队的总列表,其包含了项目中每个领域的团队:语言设计、编译器实现、基础设施、文档等。各个团队会阅读相应的提议和评论,发表自己的意见,并最终达成接受或回绝功能的一致。
任何人都可以编写 RFC 来改进 Rust, 同时这些 RFC 会被 Rust 团队评审和讨论,他们由很多不同分工的子团队组成。这里是 [Rust 官网上 ](https://www.rust-lang.org/governance ) 所有团队的总列表,其包含了项目中每个领域的团队:语言设计、编译器实现、基础设施、文档等。各个团队会阅读相应的提议和评论,发表自己的意见,并最终达成接受或回绝功能的一致。
如果功能被接受了,在 Rust 仓库会打开一个 issue, 人们就可以实现它。实现功能的人当然可能不是最初提议功能的人! 当实现完成后, 其会合并到 `master` 分支并位于一个功能开关( feature gate) 之后, 正如 [“不稳定功能” ](#不稳定功能 ) 部分所讨论的 。
如果功能被接受了,Rust 仓库里就会开一个 issue, 然后就会有人去实现它。最终完成实现的人, 很可能并不是最初提出这个功能的人! 当实现准备好之后, 它会合并到主分支, 并被放在一个 feature gate 之后,正如 [“不稳定功能” ](#不稳定功能 ) 一节所讨论的那样 。
在稍后的某个时间,一旦使用 nightly 版的 Rust 团队能够尝试这个功能了,团队成员会讨论这个功能,它如何在 nightly 中工作,并决定是否应该进入稳定版。如果决定继续推进,功能开关会移除,然后这个功能就被认为是稳定的了!乘着“发布列车”,最终在新的稳定版 Rust 中出现。
在稍后的某个时间,一旦使用 nightly 版的 Rust 团队能够尝试这个功能了,团队成员会讨论这个功能,它如何在 nightly 中工作,并决定是否应该进入稳定版。如果决定继续推进,功能开关会移除,然后这个功能就被认为是稳定的了!乘着“发布列车”,最终在新的稳定版 Rust 中出现。