|
|
|
|
@ -3,23 +3,25 @@
|
|
|
|
|
## Rust 版本说明
|
|
|
|
|
早在第一章，我们见过 `cargo new` 在 *Cargo.toml* 中增加了一些有关 `edition` 的元数据。本附录将解释其意义！
|
|
|
|
|
|
|
|
|
|
与其它语言相比，Rust的更新迭代较为频繁(得益于精心设计过的发布流程以及Rust语言开发者团队管理)：
|
|
|
|
|
与其它语言相比，Rust 的更新迭代较为频繁（得益于精心设计过的发布流程以及 Rust 语言开发者团队管理）：
|
|
|
|
|
|
|
|
|
|
- 每 6 周发布一个迭代版本
|
|
|
|
|
- 2-3年发布一个新的大版本：Rust 2021 edtion, 每一个版本会结合已经落地的功能，并提供一个清晰的带有完整更新文档和工具的功能包。新版本会作为常规的 6 周发布过程的一部分发布。
|
|
|
|
|
- 2 - 3 年发布一个新的大版本：每一个版本会结合已经落地的功能，并提供一个清晰的带有完整更新文档和工具的功能包。新版本会作为常规的 6 周发布过程的一部分发布。
|
|
|
|
|
|
|
|
|
|
好处在于，可以满足不同的用户群体的需求：
|
|
|
|
|
|
|
|
|
|
- 对于活跃的 Rust 用户，他们总是能很快获取到新的语言内容，毕竟，尝鲜是技术爱好者的共同特点:)
|
|
|
|
|
- 对于一般的用户，edition 的发布会告诉这些用户：Rust 语言相比上次大版本发布，有了重大的改进，值得一看
|
|
|
|
|
- 对于 Rust 语言开发者，可以让他们的工作成果更快的被世人所知，不必锦衣夜行
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在本文档编写时，Rust 已经有三个版本：Rust 2015、2018、2021。本书基于 Rust 2021 edition 编写。
|
|
|
|
|
在本文档编写时，Rust 已经有三个版本：Rust 2015、2018、2021。本书基于 `Rust 2021 edition` 编写。
|
|
|
|
|
|
|
|
|
|
*Cargo.toml* 中的 `edition` 字段表明代码应该使用哪个版本编译。如果该字段不存在，其默认为 `2021` 以提供后向兼容性。
|
|
|
|
|
|
|
|
|
|
每个项目都可以选择不同于默认的 2021 edition 的版本。这样，版本可能会包含不兼容的修改，比如新版本中新增的关键字可能会与老代码中的标识符冲突并导致错误。不过，除非你选择应用这些修改，否则旧代码依然能够被编译，即便你升级了编译器版本。
|
|
|
|
|
每个项目都可以选择不同于默认的 `Rust 2021 edition` 的版本。这样，版本可能会包含不兼容的修改，比如新版本中新增的关键字可能会与老代码中的标识符冲突并导致错误。不过，除非你选择应用这些修改，否则旧代码依然能够被编译，即便你升级了编译器版本。
|
|
|
|
|
|
|
|
|
|
所有 Rust 编译器都支持任何之前存在的编译器版本，并可以链接任何支持版本的包。编译器修改只影响最初的解析代码的过程。因此，如果你使用 Rust 2021 而某个依赖使用 Rust 2018，你的项目仍旧能够编译并使用该依赖。反之，若项目使用 Rust 2018 而依赖使用 Rust 2021 亦可工作。
|
|
|
|
|
所有 Rust 编译器都支持任何之前存在的编译器版本，并可以链接任何支持版本的包。编译器修改只影响最初的解析代码的过程。因此，如果你使用 `Rust 2021` 而某个依赖使用 `Rust 2018`，你的项目仍旧能够编译并使用该依赖。反之，若项目使用 `Rust 2018` 而依赖使用 `Rust 2021` 亦可工作。
|
|
|
|
|
|
|
|
|
|
有一点需要明确：大部分功能在所有版本中都能使用。开发者使用任何 Rust 版本将能继续接收最新稳定版的改进。然而在一些情况，主要是增加了新关键字的时候，则可能出现了只能用于新版本的功能。只需切换版本即可利用新版本的功能。
|
|
|
|
|
|
|
|
|
|
@ -28,14 +30,13 @@
|
|
|
|
|
|
|
|
|
|
## Rust 自身开发流程
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
本附录介绍 Rust 语言自身是如何开发的以及这如何影响作为 Rust 开发者的你。
|
|
|
|
|
|
|
|
|
|
### 无停滞稳定
|
|
|
|
|
|
|
|
|
|
作为一个语言，Rust **十分** 注重代码的稳定性。我们希望 Rust 成为你代码坚实的基础，假如持续地有东西在变，这个希望就实现不了。但与此同时，如果不能实验新功能的话，在发布之前我们又无法发现其中重大的缺陷，而一旦发布便再也没有修改的机会了。
|
|
|
|
|
|
|
|
|
|
对于这个问题我们的解决方案被称为 “无停滞稳定”（“stability without stagnation”），其指导性原则是：无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的，并应带来新功能，更少的 bug 和更快的编译速度。
|
|
|
|
|
对于这个问题我们的解决方案被称为 “无停滞稳定”（“stability without stagnation”），其指导性原则是：无需担心升级到最新的稳定版 Rust。每次升级应该是无痛的，并应带来新功能，更少的 Bug 和更快的编译速度。
|
|
|
|
|
|
|
|
|
|
### Choo, Choo! ~~ 小火车发布流程启动
|
|
|
|
|
|
|
|
|
|
@ -87,7 +88,7 @@ beta: * - - - - - - - - *
|
|
|
|
|
stable: *
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
好的！Rust 1.5 发布了！然而，我们忘了些东西：因为又过了 6 周，我们还需发布 **新版** Rust 的 beta 版，Rust 1.6。所以从 `beta` 生成 `stable` 分支后，新版的 `beta` 分支也再次从 `nightly` 生成：
|
|
|
|
|
好的！Rust 1.5 发布了！然而，我们忘了些东西：因为又过了 6 周，我们还需发布 **新版** Rust 的 beta 版，Rust 1.6。所以从 `beta` 分支生成 `stable` 分支后，新版的 `beta` 分支也再次从 `nightly` 生成：
|
|
|
|
|
|
|
|
|
|
```text
|
|
|
|
|
nightly: * - - * - - * - - * - - * - - * - * - *
|
|
|
|
|
@ -101,7 +102,7 @@ stable: *
|
|
|
|
|
|
|
|
|
|
Rust 每 6 周发布一个版本，如时钟般准确。如果你知道了某个 Rust 版本的发布时间，就可以知道下个版本的时间：6 周后。每 6 周发布版本的一个好的方面是下一班车会来得更快。如果特定版本碰巧缺失某个功能也无需担心：另一个版本很快就会到来！这有助于减少因临近发版时间而偷偷释出未经完善的功能的压力。
|
|
|
|
|
|
|
|
|
|
多亏了这个过程，你总是可以切换到下一版本的 Rust 并验证是否可以轻易的升级：如果 beta 版不能如期工作，你可以向 Rust 团队报告并在发布稳定版之前得到修复！beta 版造成的破坏是非常少见的，不过 `rustc` 也不过是一个软件，可能会存在 bug。
|
|
|
|
|
多亏了这个过程，你总是可以切换到下一版本的 Rust 并验证是否可以轻易的升级：如果 beta 版不能如期工作，你可以向 Rust 团队报告并在发布稳定版之前得到修复！beta 版造成的破坏是非常少见的，不过 `rustc` 也不过是一个软件，可能会存在 Bug。
|
|
|
|
|
|
|
|
|
|
### 不稳定功能
|
|
|
|
|
|
|
|
|
|
@ -137,13 +138,13 @@ $ cd ~/projects/needs-nightly
|
|
|
|
|
$ rustup override set nightly
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
现在，每次在 *~/需要nightly的项目/*下(在项目的根目录下，也就是Cargo.toml所在的目录) 调用 `rustc` 或 `cargo`，`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益！
|
|
|
|
|
现在，每次在 *~/需要nightly的项目/*下(在项目的根目录下，也就是 `Cargo.toml` 所在的目录) 调用 `rustc` 或 `cargo`，`rustup` 会确保使用 nightly 版 Rust。在你有很多 Rust 项目时大有裨益！
|
|
|
|
|
|
|
|
|
|
### RFC 过程和团队
|
|
|
|
|
|
|
|
|
|
那么你如何了解这些新功能呢？Rust 开发模式遵循一个 **Request For Comments (RFC) 过程**。如果你希望改进 Rust，可以编写一个提议，也就是 RFC。
|
|
|
|
|
|
|
|
|
|
任何人都可以编写 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）之后，正如[不稳定功能](#不稳定功能) 部分所讨论的。
|
|
|
|
|
|
|
|
|
|
|
Sunface
3 years ago
committed by
GitHub