2021-04-27 UTC 时间 15:09，我们发布了新版本的 Rustup (1.24.0)。UTC 时间 15:23，我们收到报告，指出我们在负责代理 Rust 工具链的 rustfmt 和 cargo-fmt 部分代码中引入了一个回归错误。UTC 时间 15:27，我们确认并确定了问题的原因，在修复问题的同时，我们将发布的 Rustup 版本回滚到 1.23.1 版本 - 此操作在 UTC 时间 15:56 完成。
这意味着，大约有 47 分钟的时间，使用 Rust 工具链代码格式化功能的 CI 作业可能会出现虚假失败，升级的用户必须回滚到 1.23.1 版本。回滚过程的设计与升级一样简单，这意味着用户不应该有遗留问题。
问题根源
为了减少下载的 rustup-init.exe 副本被重命名时造成的困惑，我们合并了一个更改，该更改会导致 Rustup 在调用二进制文件时使用未知名称时报告错误。
由于过去 rustfmt 和 cargo-fmt 这些二进制文件通过 cargo install 而不是通过 rustup component add 进行分发的复杂性，Rustup 的代理管理中对这些特定二进制文件进行了一些复杂的处理。上述问题的修复程序未在它执行的检查中包含这些特殊情况下的代理，以确保调用者未使用意外的二进制文件名称。
此时，1.24.0 版本已处于暂存阶段，但是低内存安装路径存在问题，需要进行修复，当时我们错误地评估了将版本重新基于新的 master 分支上影响较小，该分支不仅修复了低内存安装路径，还包含了上述问题的“拒绝错误名称”更改。
随后对该版本的测试几乎全部集中在安装路径上，而忽略了验证我们也在版本中获得的代理名称验证代码。结果，此回归错误被引入。
解决方案
验证 PR 的作者正确地将其确定为回归错误的根本原因，团队讨论并决定，最好正确解决问题，而不是简单地将更改从版本中回滚。
在开发修复程序时，正在协助发布过程的发布团队成员开始回滚到 Rustup 1.23.1。此外，还针对所有代理添加了一些测试（我们目前测试的是我们认为具有代表性的子集）提出了问题。随后，我们向 Rust 的开发阶段发布了提议的 1.24.1 版本，并发布了征集 Beta 测试人员的呼吁，以确认我们没有引入任何其他回归错误。
经验教训
这里最大的教训是，尽管我们从过去 Rustup 和其他工具的版本中吸取了类似的教训，但我们尚未为 Rustup 建立适当的 Beta 测试过程。因此，我们将对 Rustup 发布过程进行更改，以编纂与更广泛社区的测试阶段。
Rustup 版本的长期变更
为了尽量减少再次发生这种情况的机会，发布过程将更新为包括任何非纯错误修复版本的公开 Beta 测试阶段，并且我们打算研究针对少量平台进行“每夜” Rustup 发布的可能性。
最后，我们希望与发布团队合作，尽我们所能统一 Rustup 发布过程和成熟的 Rust 发布过程，但由于 Rustup 的发布方式存在历史差异，这可能是一项长期工作。
行动项目
如上所述，从长远来看，我们将研究 Rustup 的发布与 Rust 发布列车运行方式之间可以进行哪些统一。