即将到来的 Rust 1.0 发布意味着很多，但最根本的是对稳定性的承诺，以及我们长期以来对安全性的承诺。

从 1.0 版本开始，我们将采用 6 周的发布周期和一系列发布“渠道”。稳定发布渠道将提供无痛升级，而 nightly 渠道将让早期采用者在我们开发新功能时访问未完成的功能。

致力于稳定性

自 Rust 早期以来，只有两件事你可以指望：安全性和变化。有时甚至不是第一件事。在开发 Rust 的过程中，我们遇到了很多死胡同，因此必须有自由根据需要更改语言。

但是 Rust 已经成熟，语言的核心方面已经稳定了很长时间。设计感觉是对的。而且，人们对 Rust 积压了大量的兴趣，等待 1.0 版本的发布，以便有一个稳定的基础可以构建。

明确我们所说的稳定是什么意思非常重要。我们不是说 Rust 将停止发展。我们将定期、频繁地发布新版本的 Rust，我们希望人们也能定期升级。但要做到这一点，这些升级必须是无痛的。

简单地说，我们的责任是确保你永远不会害怕升级 Rust。如果你的代码可以在 Rust 稳定版 1.0 上编译，那么它应该以最少的麻烦在 Rust 稳定版 1.x 上编译。

计划

我们将使用火车模型的变体，该模型首先在 Web 浏览器中引入，现在被广泛用于在不停滞的情况下提供稳定性

• 新工作直接进入 master 分支。

• 每天，master 中上次成功的构建都会成为新的 nightly 版本。

• 每六周，都会从 master 的当前状态创建一个 beta 分支，而之前的 beta 分支会被提升为新的稳定版本。

简而言之，有三个发布渠道——nightly、beta 和 stable——从一个渠道到下一个渠道进行定期、频繁的升级。

新特性和新 API 将分别通过特性门和稳定性属性标记为不稳定。不稳定的特性和标准库 API 仅在 nightly 分支上可用，并且只有在您明确“选择加入”不稳定性时才可用。

另一方面，beta 和 stable 版本将仅包含被认为是稳定的特性和 API，这表示承诺避免破坏使用这些特性或 API 的代码。

常见问题

上述过程涉及很多细节，我们计划发布 RFC 来详细说明这些要点。这篇文章的其余部分将涵盖有关此计划的一些最重要的细节和潜在担忧。

1.0 版本中哪些功能将是稳定的？

我们已经对当前的 Rust 生态系统进行了分析，以确定最常用的 crate 及其依赖的特性门，并使用这些数据来指导我们的稳定化计划。好消息是，目前正在使用的大部分内容将在 1.0 版本之前稳定下来。

• 有几个功能已经接近完成：结构体变体、默认类型参数、元组索引和切片语法。

• 有两个关键功能需要更多的工作，但对于 1.0 版本至关重要：非装箱闭包和关联类型。

• 最后，有一些广泛使用的功能存在 1.0 版本无法解决的缺陷：glob 导入、宏和语法扩展。这是我们必须做出一些艰难决定的地方。

经过广泛的讨论，我们计划在 1.0 版本中将 globs 和宏作为稳定功能发布。对于 globs，我们相信我们可以以向后兼容的方式解决问题。对于宏，我们可能会在稍后提供一种定义宏的替代方法（具有更好的卫生），并且在此之前将逐步改进“macro rules”功能。1.0 版本将稳定所有当前的宏支持，包括导入/导出。

另一方面，我们不能稳定语法扩展，它们是可以完全访问编译器内部的插件。稳定它将有效地永久冻结编译器的内部结构；我们需要在扩展和编译器之间设计一个更谨慎的接口。因此，语法扩展将在 1.0 版本中保留在特性门之后。

语法扩展的许多主要用途可以用传统的代码生成来替代，Cargo 工具很快将为此用例增加特定的支持。我们计划与库作者合作，帮助他们在 1.0 版本之前从语法扩展迁移。由于许多语法扩展不符合此模型，因此我们还将稳定语法扩展视为 1.0 版本之后的当务之急。

1.0 版本中标准库的哪些部分将是稳定的？

我们一直在稳步稳定标准库，并且对它提供的几乎所有模块都有计划。预计标准库中的绝大部分功能将在 1.0 版本中稳定。我们还将更多的实验性 API 从标准库迁移到它们自己的 crate 中。

标准库之外的稳定性属性呢？

库作者可以像今天一样继续使用稳定性属性来标记他们自己的稳定性承诺。默认情况下，这些属性不会绑定到 Rust 发布渠道。也就是说，当你在 Rust 稳定版上编译时，你只能使用标准库中的稳定 API，但你可以选择使用其他库中的实验性 API。Rust 发布渠道旨在使升级Rust 本身（编译器和标准库）变得无痛。

库作者应该遵循 semver；我们将很快发布一个 RFC，定义库稳定性属性和 semver 如何交互。

为什么不允许在稳定版本中选择加入不稳定性？

允许在稳定版本中使用不稳定功能存在三个问题。

首先，正如网络多次显示的那样，仅仅宣传不稳定性是行不通的。一旦功能被广泛使用，就很难更改它们——而且一旦功能可用，就很难阻止它们被使用。网络上像“供应商前缀”这样的机制，旨在支持实验，反而导致了事实上的标准化。

其次，不稳定的功能在定义上是正在进行的工作。但是 beta/stable 快照会在计划的时间点冻结该功能，而库作者将希望使用该功能的最新版本。

最后，除非我们强制执行，否则我们根本无法为 Rust 提供稳定性。我们的承诺是，如果你使用的是 Rust 的稳定版本，你永远不会害怕升级到下一个版本。如果库可以选择加入不稳定性，那么只有在所有库作者通过同时支持所有三个发布渠道来保证相同的事情时，我们才能保持这一承诺。

整个生态系统完美地处理这些问题是不现实或没有必要的。相反，我们将强制执行稳定意味着稳定：稳定渠道仅提供稳定的功能。

这不会分裂生态系统吗？每个人都会在 1.0 版本中使用 nightly 版本吗？

它不会分裂生态系统：它会创建一个子集。使用 nightly 发布渠道的程序员可以自由使用为稳定渠道设计的库。稳定重要特性和 API 将会存在压力，因此留在不稳定世界的动机将随着时间的推移而缩小。

我们已经仔细计划了 1.0 版本，以便现有生态系统的大部分内容都将适合“稳定”类别，因此 Rust 的新来者将能够立即在稳定版 1.0 上使用大多数库。

稳定性警告是什么？

我们保留修复编译器错误、修补安全漏洞以及以可能偶尔需要新类型注释的方式更改类型推断的权利。我们不希望这些更改在升级 Rust 时引起任何麻烦。

库 API 警告将在即将发布的 RFC 中列出，但其设计也是为了最大程度地减少实际中的升级痛苦。

Rust 及其生态系统将继续快速发展吗？

是的！因为新工作可以随时进入 master，所以火车模型不会减慢开发速度或引入人为的延迟。Rust 一直以惊人的速度发展，在优秀的社区成员的帮助下，我们预计这将只会加速。