From 4e5c76fd250a7d25c852b93357ee78ee4763cb88 Mon Sep 17 00:00:00 2001 From: Hector PENG Date: Sat, 2 May 2026 03:49:39 +0800 Subject: [PATCH] Updated 'src/appendix/releases.md'. --- src/appendix/releases.md | 47 ++++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 24 deletions(-) diff --git a/src/appendix/releases.md b/src/appendix/releases.md index af2eea1..71a3889 100644 --- a/src/appendix/releases.md +++ b/src/appendix/releases.md @@ -1,40 +1,32 @@ -# 附录 G - Rust 是怎样构造出来的与每日发布 +# 附录 G - Rust 的构造方式与 “每日” 发布 -**How Rust is Made and "Nightly Rust"** - -此附录是有关 Rust 被怎样构造出来，及那会怎样作为一名 Rust 开发者的你。 +这个附录介绍 Rust 的构造方式，以及这种方式会对咱们作为 Rust 开发者有何影响。 -## 强调稳定却并无止步不前 +## 稳定而不停滞 -**Stability Without Stagnation** +作为一门编程语言，Rust *非常* 注重代码的稳定性。我们希望 Rust 成为咱们可以在其上构建软件的稳固基础，若物件不断变化，那是不可能的。与此同时，若我们无法实验一些新特性，我们可能直到他们发布后才能发现重要的缺陷，那么我们已无法再改变了。 - -作为一门语言，Rust 在注重咱们代码稳定性方面 *用心良苦*。咱们希望 Rust 成为你可以在其上构建软件的稳固基础，而若那些物件都一直变动，那将是不可能实现的。而与此同时，若咱们无法实验一些新特性，那么直到这些特性发布后咱们不能在修改一些东西时，咱们也不会发现一些重大缺陷。 - -对于这个问题，咱们（Rust 团队）的解决方案就是咱们称作 “强调稳定又不要止步不前”，而咱们的直到原则是这样的：你永不必害怕升级到稳定的Rust 新版本。每次升级都应是无痛的，而又应带给你一些新特性、更少的程序错误，以及更快的编译时间。 +我们（Rust 团队）对这个问题的解决方案就是，我们称为 “稳定而不停滞，stability without stagnation”，我们的指导原则是：咱们绝不应该担心升级到新版本的稳定 Rust。每次升级都应是无痛的，而应带给咱们新特性、更少的 bug 以及更快的编译时间。 ## 啾，啾！发布通道与搭上快车 -**Choo, Choo! Release Channels and Riding the Trains** - - -Rust 的开发，是运作在 *火车时刻表，train schedule* 上的。那就是说，全部开发都是在 Rust 代码仓库的 `master` 分支上完成的。各个发布遵循了软件发布列车模型，a software release train model，该发布模型业已为 Cisco IOS 及其他软件项目所使用。Rust 有着以下三个 *发布通道，release channels*： +Rust 的开发按照 *火车时刻表，train schedule* 进行。也就是说，所有开发都是在 Rust 代码仓库的主分支上完成的。发布遵循软件 “发布列车” 模型，a software release train model，该发布模型已被 Cisco IOS 及其他软件项目使用。Rust 共有三个 *发布通道，release channels*： - 每日发布，nightly - Beta 发布，beta - 稳定发布，stable -多数 Rust 开发者主要使用稳定通道，而那些希望尝试实验性新特性的人们，则会使用每日发布或 beta 通道。 +大多数 Rust 开发者主要使用稳定通道，而那些希望尝试实验性新特性的人可能会使用每日发布或 beta 发布。 -下面是个开发与发布流程运作方式的一个示例：咱们来假定 Rust 团队正工作于 Rust 1.5 的发布上。那个发布发生于 2015 年 11 月，但其将提供到我们实际版本数字。有个新特性被添加到 Rust：一次新提交落在了 `master` 分支。每天晚上，都有一个新的 Rust 每日版本被产生出来。每天都是个发布日，而这些发布是由咱们的发布基础设施自动创建的。因此随着时间流逝，咱们的发布看起来就像下面这样，每晚一次： +以下是个开发和发布流程工作方式的示例：假设 Rust 团队正在准备 Rust 1.5 的发布。这一发布发生于 2015 年 11 月，而他将向我们提供实际的版本编号。一项新的特性会添加到 Rust：一次新提会在主分支上落实。每天晚上，一个新的 Rust 每日版本都会得以产生。每天都是发布日，而这些发布都是由我们的发布基础设施自动创建。因此随着时间的推移，我们的发布看起来像下面这样，每晚一次： ```text nightly: * - - * - - * ``` -每隔六周，便是要准备一个新发布的时候了！Rust 代码仓库的 `beta` 分支，便会从由每日发布所使用的 `master` 分支分叉开来。现在，就有了两个分支： +每六周，就到了准备新发布的时候了！Rust 代码仓库的 `beta` 分支，会从由每日发布使用的主分支中分叉出来。现在，共有两个发布： ```text nightly: * - - * - - * @@ -42,7 +34,7 @@ nightly: * - - * - - * beta: * ``` -多数 Rust 使用者不会积极使用这些 beta 发布，但会在他们的 CI 系统中就 beta 发布加以测试，以帮助 Rust 发现可能出现的倒退。与此同时，仍有着每晚的每日发布： +大多数 Rust 用户不会主动使用 beta 发布，但会在持续集成 CI 系统中测试 beta 发布，以帮助 Rust 发现可能出现的回归问题。与此同时，仍有每晚的每日发布： ```text nightly: * - - * - - * - - * - - * @@ -50,7 +42,15 @@ nightly: * - - * - - * - - * - - * beta: * ``` -在首个 beta 版创建出来六周后，就是稳定发布的时候了！`stable` 分支就被从 `beta` 分支创建出来： +假设某个回归问题被找到。在回归问题进入稳定发布之前，幸好我们还有时间测试 beta 发布！修复会应用到主分支，因此每日发布得以修复，然后修复得以反向移植到 `beta` 分支，进而一个新的 beta 发布得以产生： + +```text +nightly: * - - * - - * - - * - - * - - * + | +beta: * - - - - - - - - * +``` + +首个 beta 发布六周后，是时候推出稳定发布了！`stable` 分支产生自 `beta` 分支： ```text nightly: * - - * - - * - - * - - * - - * - * - * @@ -60,7 +60,7 @@ beta: * - - - - - - - - * stable: * ``` -好！Rust 1.5 便完成了！不过，咱们忘了一件事：由于这六个星期以及过去，而咱们还需要 Rust *下一* 版本，1.6，的一个新的 beta 发布。因此在 `stale` 分支从 `beta` 分支分叉出来后，下一版本的 `beta` 又会从 `nightly` 再度分叉出来： +太棒了！Rust 1.5 完成了！不过，我们忘记了一件事：由于这六周已经过去，我们还需要 Rust *下一* 版本 1.6 的新 beta 发布。因此在 `stale` 分支从 `beta` 分支分叉出后，下一版本的 `beta` 分支，又会从 `nightly` 分叉出来： ```text nightly: * - - * - - * - - * - - * - - * - * - * @@ -70,12 +70,11 @@ beta: * - - - - - - - - * * stable: * ``` -每六周就有一个发布 “离站”，但发布过程仍务必要在其抵达稳定发布前，经由这个 beta 通道行驶一段路程，由此这个过程便被称为 “列车模型”。 +这被称为 “列车模型”，因为每六周，就会有一个发布 “出站”，但在作为稳定发布之前，仍然必须经历 beta 通道。 -Rust 每六周发布，像时刻表一样。若咱们知道了一个 Rust 发布的日期，那么就能直到下一发布的日期：那便是六周后。每六周安排一次发布的一个好处，便是下一班列车很快就会到来。若某项特性刚好错过了某个特定发布，那么无需担心：另一发布将在不久后发生！这有助于减少在临近发布截止日期时，有可能未完善的功能偷偷潜入的压力。 +Rust 每六周发布一次，就像时刻表一样。当咱们知道某次 Rust 发布的日期，就可以知道下一发布的日期：那就是六周后。每六周安排一次发布的一个好处是，下一班列车很快就会到来。若某项特性碰巧错过了某个特定发布，也无需担心：另一个发布很快就会出现！这有助于减少在发布截止日期邻近时，塞入可能尚未打磨完善的特性所带来的压力。 - -归功于这个流程，咱们可以始终检出，check out，下一构建的 Rust，并自己验证到升级是容易的：若 beta 发布没有如预期那样工作，咱们就可以将其报告给 Rust 团队，并在下一稳定发布发生前修好他！beta 发布中的损坏相对较少，但 `rustc` 仍属于一个软件，而确实存在一些错误。 +得益于这一流程，咱们可以始终检出，check out，下一构建的 Rust，并自己验证到升级是容易的：若 beta 发布没有如预期那样工作，咱们就可以将其报告给 Rust 团队，并在下一稳定发布发生前修好他！beta 发布中的损坏相对较少，但 `rustc` 仍属于一个软件，而确实存在一些错误。 ## 不稳定特性