附录 G - Rust 是怎样构造出来的与每日发布
How Rust is Made and "Nightly Rust"
此附录是有关 Rust 被怎样构造出来，及那会怎样作为一名 Rust 开发者的你。
强调稳定却并无止步不前
Stability Without Stagnation
作为一门语言，Rust 在注重咱们代码稳定性方面 用心良苦。咱们希望 Rust 成为你可以在其上构建软件的稳固基础，而若那些物件都一直变动，那将是不可能实现的。而与此同时，若咱们无法实验一些新特性，那么直到这些特性发布后咱们不能在修改一些东西时，咱们也不会发现一些重大缺陷。
对于这个问题，咱们（Rust 团队）的解决方案就是咱们称作 “强调稳定又不要止步不前”，而咱们的直到原则是这样的：你永不必害怕升级到稳定的Rust 新版本。每次升级都应是无痛的，而又应带给你一些新特性、更少的程序错误，以及更快的编译时间。
啾，啾！发布通道与搭上快车
Choo, Choo! Release Channels and Riding the Trains
Rust 的开发，是运作在 火车时刻表，train schedule 上的。那就是说，全部开发都是在 Rust 代码仓库的 master 分支上完成的。各个发布遵循了软件发布列车模型，a software release train model，该发布模型业已为 Cisco IOS 及其他软件项目所使用。Rust 有着以下三个 发布通道，release channels：
- 每日发布，nightly
- Beta 发布，beta
- 稳定发布，stable
多数 Rust 开发者主要使用稳定通道，而那些希望尝试实验性新特性的人们，则会使用每日发布或 beta 通道。
下面是个开发与发布流程运作方式的一个示例：咱们来假定 Rust 团队正工作于 Rust 1.5 的发布上。那个发布发生于 2015 年 11 月，但其将提供到我们实际版本数字。有个新特性被添加到 Rust：一次新提交落在了 master 分支。每天晚上，都有一个新的 Rust 每日版本被产生出来。每天都是个发布日，而这些发布是由咱们的发布基础设施自动创建的。因此随着时间流逝，咱们的发布看起来就像下面这样，每晚一次：
nightly: * - - * - - *
每隔六周，便是要准备一个新发布的时候了！Rust 代码仓库的 beta 分支，便会从由每日发布所使用的 master 分支分叉开来。现在，就有了两个分支：
nightly: * - - * - - *
|
beta: *
多数 Rust 使用者不会积极使用这些 beta 发布，但会在他们的 CI 系统中就 beta 发布加以测试，以帮助 Rust 发现可能出现的倒退。与此同时，仍有着每晚的每日发布：
nightly: * - - * - - * - - * - - *
|
beta: *
在首个 beta 版创建出来六周后，就是稳定发布的时候了！stable 分支就被从 beta 分支创建出来：
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
好！Rust 1.5 便完成了！不过，咱们忘了一件事：由于这六个星期以及过去，而咱们还需要 Rust 下一 版本，1.6，的一个新的 beta 发布。因此在 stale 分支从 beta 分支分叉出来后，下一版本的 beta 又会从 nightly 再度分叉出来：
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
每六周就有一个发布 “离站”，但发布过程仍务必要在其抵达稳定发布前，经由这个 beta 通道行驶一段路程，由此这个过程便被称为 “列车模型”。
Rust 每六周发布，像时刻表一样。若咱们知道了一个 Rust 发布的日期，那么就能直到下一发布的日期：那便是六周后。每六周安排一次发布的一个好处，便是下一班列车很快就会到来。若某项特性刚好错过了某个特定发布，那么无需担心：另一发布将在不久后发生！这有助于减少在临近发布截止日期时，有可能未完善的功能偷偷潜入的压力。
归功于这个流程，咱们可以始终检出，check out，下一构建的 Rust，并自己验证到升级是容易的：若 beta 发布没有如预期那样工作，咱们就可以将其报告给 Rust 团队，并在下一稳定发布发生前修好他！beta 发布中的损坏相对较少，但 rustc 仍属于一个软件，而确实存在一些错误。
不稳定特性
Unstable Features
这种发布模型下，还有一个好处：不稳定特性。Rust 使用了一种名为 “特性标识，feature flags” 的技巧，来确定出给定发布中启用了哪些特性。若某项新特性处于活跃开发中，他就会落地在 master 分支上，而由此就会在每日发布中，但会有着一个 特性标识。而咱们，作为用户，希望尝试这个进展中的特性，the work-in-progress feature，时，咱们是可以尝试的，但必须使用 Rust 的每日发布，并使用恰当的标识来注解咱们的代码，来选用该特性。
若咱们使用着 beta 或稳定发布的 Rust，那么就不能使用任何特性标识。这是 Rust 团队在声明那些新特性永久稳定前，允许咱们实际用到他们的关键。希望选用最新特性的人们，便可这样做，而想要一种扎实体验的人，则可坚持使用稳定发布，而清楚他们的代码不会破坏。这便是稳定但并非止步不前。
由于那些工作中的特性仍在便会，且在本书写作时和他们在稳定构建中启用时，其间他们肯定将有所不同，因此本书只包含了那些稳定特性的信息。咱们可以在线上找到那些仅每日发布有的特性文档。
Rustup 与 Rust 每日发布所扮演的角色
Rustup and the Role of Rust Nightly
Rust 令到易于在全局或每个项目基础上，从不同发布通道的 Rust 之间改变。默认情况下，咱们将安装稳定发布的 Rust。而比如要安装每日发布：
$ rustup toolchain install nightly
咱们也可以使用 rustup，查看全部的 工具链，toolchains （Rust 的各个发布与关联组件）。下面就是本书一位作者的 Windows 计算机上的示例：
> rustup toolchain list
stable-x86_64-pc-windows-msvc (default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
在 Linux 系统上的输出如下：
$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)
可以看到，稳定发布的工具链是默认的。绝大多数 Rust 用户会在多数时候使用稳定发布。咱们可能想要在多数时候使用稳定发布，又因为咱们关心某项最新特性，而会在特定项目使用每日发布。要这样做，就可以在那个项目目录下，使用 rustup override 来将每日发布工具链，设置为当咱们位处那个目录中时，rustup 使用的那个工具链：
$ cd ~/projects/needs-nightly
$ rustup override set nightly
现在，当咱们每次在 ~/projects/needs-nightly 目录下调用 rustc 或 cargo 时，rustup 都会确保咱们在使用每日发布的 Rust，而非咱们默认的稳定发布 Rust 了。再有很多 Rust 项目时，这就会排上用场!
请求评议流程与各种团队
The RFC Process and Teams
那么咱们该怎么了解到这些新特性呢？Rust 的开发模型，遵循了 请求评议流程，Request For Comments(RFC) process。如你想要 Rust 的一项改进，那么就可以编写一个名为请求评议，RFC 的提议。
人人都可以编写请求评议来改进 Rust，同时这些提议会经过由许多议题子团队所组成的 Rust 团队审阅和讨论。在 Rust 网站上 有这些团队的完整清单，其中包括了该项目各领域：语言设计、编译器实现、基础设施、文档及其他等的团队。恰当的团队会阅读提议与评论，撰写出他们自己的一些评论，并在最后，便有了接受或拒绝该特性的共识。
若该特性被接受了，就会在 Rust 代码仓库上开出一个 issue，同时某个人就可以实现他。将其实现得非常棒的那个人，可能不是最早提议这项特性的那人！在实现准备好时，其就会落地于 master 分支的特性门，a feature gate，之后，如同咱们曾在 “不稳定特性” 小节中曾讨论过的那样。
过了一段时间后，一旦那些用到每日发布的 Rust 开发者们，能够试用这项新特性，那么 Rust 团队成员将讨论这项特性，怎样将其编制到每日发布上，并决定其是否有那个被构造到稳定发布 Rust。而若决定是继续推进，那么特性门就会被移除，同时这项特性就被认为是稳定的了！他就会搭上列车，进到一个新的稳定发布 Rust 中。