|
|
@ -1,7 +1,7 @@
|
|
|
|
## 附录E Rust自身开发流程
|
|
|
|
## 附录E Rust自身开发流程
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
本附录介绍 Rust 是如何开发的以及这如何影响作为 Rust 开发者的你。
|
|
|
|
本附录介绍 Rust语言自身是如何开发的以及这如何影响作为 Rust 开发者的你。
|
|
|
|
|
|
|
|
|
|
|
|
### 无停滞稳定
|
|
|
|
### 无停滞稳定
|
|
|
|
|
|
|
|
|
|
|
@ -9,9 +9,9 @@
|
|
|
|
|
|
|
|
|
|
|
|
对于这个问题我们的解决方案被称为 “无停滞稳定”(“stability without stagnation”),其指导性原则是:无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的,并应带来新功能,更少的 bug 和更快的编译速度。
|
|
|
|
对于这个问题我们的解决方案被称为 “无停滞稳定”(“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
|
|
|
|
* Nightly
|
|
|
|
* Beta
|
|
|
|
* Beta
|
|
|
@ -19,7 +19,7 @@ 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 新增了一项功能:一个 `master` 分支的新提交。每天晚上,会产生一个新的 nightly 版本。每天都是发布版本的日子,而这些发布由发布基础设施自动完成。所以随着时间推移,发布轨迹看起来像这样,版本一天一发:
|
|
|
|
|
|
|
|
|
|
|
|
```text
|
|
|
|
```text
|
|
|
|
nightly: * - - * - - *
|
|
|
|
nightly: * - - * - - *
|
|
|
@ -107,7 +107,7 @@ $ cd ~/projects/needs-nightly
|
|
|
|
$ rustup override set nightly
|
|
|
|
$ rustup override set nightly
|
|
|
|
```
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
现在,每次在 *~/projects/needs-nightly* 调用 `rustc` 或 `cargo`,`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益!
|
|
|
|
现在,每次在 *~/需要nightly的项目/*下(在项目的根目录下,也就是Cargo.toml所在的目录) 调用 `rustc` 或 `cargo`,`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益!
|
|
|
|
|
|
|
|
|
|
|
|
### RFC 过程和团队
|
|
|
|
### RFC 过程和团队
|
|
|
|
|
|
|
|
|
|
|
@ -115,6 +115,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)之后,正如 [“不稳定功能”](#unstable-features) 部分所讨论的。
|
|
|
|
如果功能被接受了,在 Rust 仓库会打开一个 issue,人们就可以实现它。实现功能的人可能不是最初提议功能的人!当实现完成后,其会合并到 `master` 分支并位于一个特性开关(feature gate)之后,正如 [不稳定功能](#不稳定功能) 部分所讨论的。
|
|
|
|
|
|
|
|
|
|
|
|
在稍后的某个时间,一旦使用 nightly 版的 Rust 团队能够尝试这个功能了,团队成员会讨论这个功能,它如何在 nightly 中工作,并决定是否应该进入稳定版。如果决定继续推进,功能开关会移除,然后这个功能就被认为是稳定的了!乘着“发布的列车”,最终在新的稳定版 Rust 中出现。
|
|
|
|
在稍后的某个时间,一旦使用 nightly 版的 Rust 团队能够尝试这个功能了,团队成员会讨论这个功能在 nightly 中运行的情况,并决定是否应该进入稳定版。如果决定继续推进,特性开关会移除,然后这个功能就被认为是稳定的了!乘着“发布的列车”,最终在新的稳定版 Rust 中出现。
|
|
|
|