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

从 1.0 版本开始，我们将采用 6 周的发布周期和发布“通道”菜单。稳定发布通道将提供无痛升级，而 nightly 通道将使早期采用者能够在我们开发过程中访问未完成的功能。

承诺稳定性

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

但 Rust 已经成熟，语言的核心方面已经稳定了很长时间。设计感觉很正确。并且有大量的积压兴趣在等待 Rust 1.0 发布，以便有一个稳定的基础来构建。

重要的是要清楚我们所说的稳定性是什么意思。我们并不意味着 Rust 将停止发展。我们将定期发布新版本的 Rust，我们希望人们也能定期升级。但要做到这一点，这些升级需要无痛。

简而言之，我们的责任是确保你永远不会害怕升级 Rust。如果你的代码在 Rust stable 1.0 上编译，它应该在 Rust stable 1.x 上编译，并且只需最少的麻烦。

计划

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

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

• 每天，来自 master 的最后一个成功构建将成为新的 nightly 版本。

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

简而言之，有三个发布通道——nightly、beta 和 stable——它们之间有规律的、频繁的升级。

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

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

常见问题解答

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

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

我们对当前的 Rust 生态系统进行了分析，以确定使用最多的板条箱以及它们依赖的功能门，并利用这些数据指导我们的稳定计划。好消息是，目前正在使用的大部分内容将在 1.0 版本中稳定。

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

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

• 最后，有一些广泛使用的功能存在缺陷，无法在 1.0 版本的时间范围内解决：全局导入、宏和语法扩展。这是我们必须做出一些艰难决定的部分。

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

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

语法扩展的许多主要用途可以用传统的代码生成来代替，Cargo 工具很快就会为这种情况提供专门的支持。我们计划与库作者合作，帮助他们在 1.0 版本之前从语法扩展迁移。由于许多语法扩展不符合这种模式，我们也认为稳定语法扩展是 1.0 版本发布后的首要任务。

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

我们一直在稳定标准库，并且有一个计划几乎涵盖它提供的所有模块。预计标准库中的绝大多数功能将在 1.0 版本中稳定。我们还一直在将更多实验性 API 从标准库迁移到它们自己的板条箱中。

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

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

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

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

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

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

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

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

整个生态系统完美地解决这些问题是不现实的，也不必要。相反，我们将强制执行稳定意味着稳定：稳定通道只提供稳定功能。

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

它不会分裂生态系统：它创建了一个子集。使用 nightly 发布通道的程序员可以自由地使用为稳定通道设计的库。将有压力来稳定重要的功能和 API，因此随着时间的推移，留在不稳定世界中的动机将减少。

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

稳定性有哪些注意事项？

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

库 API 注意事项将在即将发布的 RFC 中列出，但同样旨在最大限度地减少实际升级中的麻烦。

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

是的！因为新工作可以随时进入 master，所以火车模型不会减缓开发速度或引入人为延迟。Rust 一直以惊人的速度发展，得到了来自社区成员的大量帮助，我们预计这种情况只会加速。