Update src/appendix-07-nightly-rust.md

src/appendix-07-nightly-rust.md

@@ -2,29 +2,29 @@
 
 本附录介绍 Rust 是如何开发的以及这如何影响作为 Rust 开发者的你。
 
-### 无停滞稳定
+### 稳定而不停滞
 
-作为一个语言，Rust **十分** 注重代码的稳定性。我们希望 Rust 成为你代码坚实的基础，假如持续地有东西在变，这个希望就实现不了。但与此同时，如果不能实验新功能的话，在发布之前我们又无法发现其中重大的缺陷，而一旦发布便再也没有修改的机会了。
+作为一个语言，Rust **非常**关心代码的稳定性。我们希望 Rust 成为你代码的坚实基础，假如持续地有东西在变，这个希望就实现不了。与此同时，如果不能试验新功能的话，在发布之前我们又无法发现其中重大的缺陷，而一旦发布便再也没有修改的机会了。
 
-对于这个问题我们的解决方案被称为 “无停滞稳定”（“stability without stagnation”），其指导性原则是：无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的，并应带来新功能，更少的 bug 和更快的编译速度。
+对于这个问题我们的解决方案被称为 “稳定而不停滞”（“stability without stagnation”），其指导性原则是：无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的，并带来新功能，更少的 bug 和更快的编译速度。
 
-### Choo, Choo! ~~（开车啦，逃）~~ 发布通道和发布时刻表（Riding the Trains）
+### 发布通道和乘坐火车
 
-Rust 开发运行于一个 ~~车次表~~ **发布时刻表**（*train schedule*）之上。也就是说，所有的开发工作都位于 Rust 仓库的 `master` 分支。发布采用 software release train 模型，其被用于思科 IOS 等其它软件项目。Rust 有三个 **发布通道**（*release channel*）：
+Rust 开发按照**火车时刻表**（*train schedule*）运行。也就是说，所有的开发工作都是在 Rust 仓库的 `master` 分支上完成的。Rust 发布采用火车模型发布模式（software release train model），其被用于思科 IOS 和其它软件项目。Rust 有三个**发布通道**（*release channel*）：
 
-* Nightly
+* Nightly（开发版）
-* Beta
+* Beta（预览版）
 * Stable（稳定版）
 
-大部分 Rust 开发者主要采用稳定版通道，不过希望实验新功能的开发者可能会使用 nightly 或 beta 版。
+大部分 Rust 开发者主要采用稳定版通道，不过希望实验新功能的开发者可能会使用开发版或预览版。
 
-如下是一个开发和发布过程如何运转的例子：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，不过这里只是为了提供一个真实的版本。Rust 新增了一项功能：一个 `master` 分支的新提交。每天晚上，会产生一个新的 nightly 版本。每天都是发布版本的日子，而这些发布由发布基础设施自动完成。所以随着时间推移，发布轨迹看起来像这样，版本一天一发：
+下面是一个开发和发布过程如何运转的示例：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，但它将为我们提供真实的版本号。Rust 新增了一项功能：一个新的提交到 `master` 分支。每天晚上，会产生一个新的开发版（nightly 版）Rust。每天都是发布日，而这些发布由发布基础设施自动创建。所以随着时间推移，发布轨迹看起来像这样，每晚一次：
 
 ```text
 nightly: * - - * - - *
 ```
 
-每 6 周时间，是准备发布新版本的时候了！Rust 仓库的 `beta` 分支会从用于 nightly 的 `master` 分支产生。现在，有了两个发布版本：
+每 6 周，是时候准备一个新版本了！Rust 仓库的 `beta` 分支会从开发版的 `master` 分支分出来。现在，有了两个发布版本：
 
 ```text
 nightly: * - - * - - *
@@ -32,7 +32,7 @@ nightly: * - - * - - *
 beta:                *
 ```
 
-大部分 Rust 用户不会主要使用 beta 版本，不过在 CI 系统中对 beta 版本进行测试能够帮助 Rust 发现可能的回归缺陷（regression）。同时，每天仍产生 nightly 发布：
+大部分 Rust 用户不会主动使用 beta 发布版本，不过在 CI 系统（持续集成系统）中对 beta 版本进行测试能帮助 Rust 发现可能的回归缺陷（regression）。同时，每晚仍产生开发发布版：
 
 ```text
 nightly: * - - * - - * - - * - - *
@@ -40,7 +40,7 @@ nightly: * - - * - - * - - * - - *
 beta:                *
 ```
 
-比如我们发现了一个回归缺陷。好消息是在这些缺陷流入稳定发布之前还有一些时间来测试 beta 版本！修复被合并到 `master`，为此 nightly 版本得到了修复，接着这些修复将并入到 `beta` 分支，一个新的 beta 发布就产生了：
+比如我们发现了一个回归缺陷。好消息是在这些缺陷流入稳定发布之前还有一些时间来测试 beta 版本！修复在 `master` 分支进行，从而 nightly 版本得到了修复，接着将这些修复向后移植到 `beta` 分支，一个新的 beta 发布就产生了：
 
 ```text
 nightly: * - - * - - * - - * - - * - - *
@@ -48,7 +48,7 @@ nightly: * - - * - - * - - * - - * - - *
 beta:                * - - - - - - - - *
 ```
 
-第一个 beta 版的 6 周后，是发布稳定版的时候了！`stable` 分支从 `beta` 分支生成：
+在创建第一个 beta 版 6 周后，是时候发布稳定版本了！`stable` 分支从 `beta` 分支生成：
 
 ```text
 nightly: * - - * - - * - - * - - * - - * - * - *
@@ -58,7 +58,7 @@ beta:                * - - - - - - - - *
 stable:                                *
 ```
 
-好的！Rust 1.5 发布了！然而，我们忘了些东西：因为又过了 6 周，我们还需发布 **新版** Rust 的 beta 版，Rust 1.6。所以从 `beta` 生成 `stable` 分支后，新版的 `beta` 分支也再次从 `nightly` 生成：
+好极了！Rust 1.5 发布了！然而，我们忘了些东西：因为 6 周过去了，我们还需发布**下一个** Rust 1.6 的全新 beta 版本。所以从 `beta` 生成 `stable` 分支后，下一版的 `beta` 分支也再次从 `nightly` 生成：
 
 ```text
 nightly: * - - * - - * - - * - - * - - * - * - *
@@ -68,11 +68,11 @@ beta:                * - - - - - - - - *       *
 stable:                                *
 ```
 
-这被称为 “train model”，因为每 6 周，一个版本 “离开车站”（“leaves the station”），不过从 beta 通道到达稳定通道还有一段旅程。
+这被称为“火车模式”（train model），因为每 6 周，一个版本“离开车站”，不过从 beta 通道到达稳定通道还有一段旅程。
 
-Rust 每 6 周发布一个版本，如时钟般准确。如果你知道了某个 Rust 版本的发布时间，就可以知道下个版本的时间：6 周后。每 6 周发布版本的一个好的方面是下一班车会来得更快。如果特定版本碰巧缺失某个功能也无需担心：另一个版本很快就会到来！这有助于减少因临近发版时间而偷偷释出未经完善的功能的压力。
+Rust 每 6 周发布一次，就像发条一样。如果你知道了某个 Rust 版本的发布日期，就可以知道下个版本的日期：6 周后。每 6 周发布一版的一个好处是下一班火车即将到来。如果一个功能在特定版本中错过了也无需担心：另一个版本很快就会到来！这有助于减少在发布截止日期前匆忙加入可能未完善的功能的压力。
 
-多亏了这个过程，你总是可以切换到下一版本的 Rust 并验证是否可以轻易的升级：如果 beta 版不能如期工作，你可以向 Rust 团队报告并在发布稳定版之前得到修复！beta 版造成的破坏是非常少见的，不过 `rustc` 也不过是一个软件，可能会存在 bug。
+多亏了这个过程，你可以随时切换到下一版本的 Rust 并验证它是否易于升级：如果 beta 版不能如期工作，你可以向 Rust 团队报告并在发布下一个稳定版之前得到修复！beta 版造成的破坏是非常少见的，但 `rustc` 也是一个软件，仍可能存在 bug。
 
 ### 不稳定功能
 
@@ -110,10 +110,10 @@ $ rustup override set nightly
 
 ### RFC 过程和团队
 
-那么你如何了解这些新功能呢？Rust 开发模式遵循一个 **Request For Comments (RFC) 过程**。如果你希望改进 Rust，可以编写一个提议，也就是 RFC。
+那么你如何了解这些新功能呢？Rust 开发模式遵循一个 **Request For Comments (RFC，征求评审) 过程**。如果你希望改进 Rust，可以编写一个提议，也就是 RFC。
 
 任何人都可以编写 RFC 来改进 Rust，同时这些 RFC 会被 Rust 团队评审和讨论，他们由很多不同分工的子团队组成。这里是 [Rust 官网上](https://www.rust-lang.org/governance) 所有团队的总列表，其包含了项目中每个领域的团队：语言设计、编译器实现、基础设施、文档等。各个团队会阅读相应的提议和评论，编写回复，并最终达成接受或回绝功能的一致。
 
-如果功能被接受了，在 Rust 仓库会打开一个 issue，人们就可以实现它。实现功能的人当然可能不是最初提议功能的人！当实现完成后，其会合并到 `master` 分支并位于一个功能开关（feature gate）之后，正如 [“不稳定功能”](#unstable-features) 部分所讨论的。
+如果功能被接受了，在 Rust 仓库会打开一个 issue，人们就可以实现它。实现功能的人当然可能不是最初提议功能的人！当实现完成后，其会合并到 `master` 分支并位于一个功能开关（feature gate）之后，正如 [“不稳定功能”](#unstable-features)<!-- ignore --> 章节所讨论的。
 
 在稍后的某个时间，一旦使用 nightly 版的 Rust 团队能够尝试这个功能了，团队成员会讨论这个功能，它如何在 nightly 中工作，并决定是否应该进入稳定版。如果决定继续推进，功能开关会移除，然后这个功能就被认为是稳定的了！乘着“发布的列车”，最终在新的稳定版 Rust 中出现。