|
|
|
|
@ -1,7 +1,7 @@
|
|
|
|
|
## 附录E Rust自身开发流程
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
本附录介绍 Rust 是如何开发的以及这如何影响作为 Rust 开发者的你。
|
|
|
|
|
本附录介绍 Rust语言自身是如何开发的以及这如何影响作为 Rust 开发者的你。
|
|
|
|
|
|
|
|
|
|
### 无停滞稳定
|
|
|
|
|
|
|
|
|
|
@ -9,9 +9,9 @@
|
|
|
|
|
|
|
|
|
|
对于这个问题我们的解决方案被称为 “无停滞稳定”（“stability without stagnation”），其指导性原则是：无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的，并应带来新功能，更少的 bug 和更快的编译速度。
|
|
|
|
|
|
|
|
|
|
### Choo, Choo! ~~（开车啦，逃）~~ 发布通道和发布时刻表（Riding the Trains）
|
|
|
|
|
### Choo, Choo! ~~ 小火车发布流程启动
|
|
|
|
|
|
|
|
|
|
Rust 开发运行于一个 ~~车次表~~ **发布时刻表**（*train schedule*）之上。也就是说，所有的开发工作都位于 Rust 仓库的 `master` 分支。发布采用 software release train 模型，其被用于思科 IOS 等其它软件项目。Rust 有三个 **发布通道**（*release channel*）：
|
|
|
|
|
开发Rust语言是基于一个**火车时刻表**来进行的：所有的开发工作在Master分支上完成，但是发布就像火车时刻表一样，拥有不同的时间，发布采用的软件发布列车模型，被用于思科IOS和等其它软件项目。Rust 有三个 **发布通道**（*release channel*）：
|
|
|
|
|
|
|
|
|
|
* Nightly
|
|
|
|
|
* Beta
|
|
|
|
|
@ -19,7 +19,7 @@ Rust 开发运行于一个 ~~车次表~~ **发布时刻表**（*train schedule*
|
|
|
|
|
|
|
|
|
|
大部分 Rust 开发者主要采用稳定版通道，不过希望实验新功能的开发者可能会使用 nightly 或 beta 版。
|
|
|
|
|
|
|
|
|
|
如下是一个开发和发布过程如何运转的例子：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，不过这里只是为了提供一个真实的版本。Rust 新增了一项功能：一个 `master` 分支的新提交。每天晚上，会产生一个新的 nightly 版本。每天都是发布版本的日子，而这些发布由发布基础设施自动完成。所以随着时间推移，发布轨迹看起来像这样，版本一天一发：
|
|
|
|
|
如下是一个开发和发布过程如何运转的例子：假设 Rust 团队正在进行 Rust 1.5 的发布工作。该版本发布于 2015 年 12 月，这个版本和时间显然比较老了，不过这里只是为了提供一个真实的版本。Rust 新增了一项功能：一个 `master` 分支的新提交。每天晚上，会产生一个新的 nightly 版本。每天都是发布版本的日子，而这些发布由发布基础设施自动完成。所以随着时间推移，发布轨迹看起来像这样，版本一天一发：
|
|
|
|
|
|
|
|
|
|
```text
|
|
|
|
|
nightly: * - - * - - *
|
|
|
|
|
@ -107,7 +107,7 @@ $ cd ~/projects/needs-nightly
|
|
|
|
|
$ rustup override set nightly
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
现在，每次在 *~/projects/needs-nightly* 调用 `rustc` 或 `cargo`，`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益！
|
|
|
|
|
现在，每次在 *~/需要nightly的项目/*下(在项目的根目录下，也就是Cargo.toml所在的目录) 调用 `rustc` 或 `cargo`，`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益！
|
|
|
|
|
|
|
|
|
|
### RFC 过程和团队
|
|
|
|
|
|
|
|
|
|
@ -115,6 +115,6 @@ $ rustup override set nightly
|
|
|
|
|
|
|
|
|
|
任何人都可以编写 RFC 来改进 Rust，同时这些 RFC 会被 Rust 团队评审和讨论，他们由很多不同分工的子团队组成。这里是 [Rust 官网上](https://www.rust-lang.org/governance) 所有团队的总列表，其包含了项目中每个领域的团队：语言设计、编译器实现、基础设施、文档等。各个团队会阅读相应的提议和评论，编写回复，并最终达成接受或回绝功能的一致。
|
|
|
|
|
|
|
|
|
|
如果功能被接受了，在 Rust 仓库会打开一个 issue，人们就可以实现它。实现功能的人当然可能不是最初提议功能的人！当实现完成后，其会合并到 `master` 分支并位于一个功能开关（feature gate）之后，正如 [“不稳定功能”](#unstable-features) 部分所讨论的。
|
|
|
|
|
如果功能被接受了，在 Rust 仓库会打开一个 issue，人们就可以实现它。实现功能的人可能不是最初提议功能的人！当实现完成后，其会合并到 `master` 分支并位于一个特性开关（feature gate）之后，正如 [不稳定功能](#不稳定功能) 部分所讨论的。
|
|
|
|
|
|
|
|
|
|
在稍后的某个时间，一旦使用 nightly 版的 Rust 团队能够尝试这个功能了，团队成员会讨论这个功能，它如何在 nightly 中工作，并决定是否应该进入稳定版。如果决定继续推进，功能开关会移除，然后这个功能就被认为是稳定的了！乘着“发布的列车”，最终在新的稳定版 Rust 中出现。
|
|
|
|
|
在稍后的某个时间，一旦使用 nightly 版的 Rust 团队能够尝试这个功能了，团队成员会讨论这个功能在 nightly 中运行的情况，并决定是否应该进入稳定版。如果决定继续推进，特性开关会移除，然后这个功能就被认为是稳定的了！乘着“发布的列车”，最终在新的稳定版 Rust 中出现。
|
|
|
|
|
|
sunface
3 years ago