Linuxeden开源社区
多年来，Cargo 团队一直鼓励 Rust 开发者提交他们的 Cargo.lock 文件，用于包含二进制文件而非库的软件包。现在，我们建议开发者选择最适合自己项目的方式。为了帮助人们做出决定，我们确实包含了一些考虑因素，并建议将提交 Cargo.lock 作为决策的起点。为了与这一出发点保持一致，从 nightly-2023-08-24 开始，cargo new 将不再忽略 Cargo.lock 库。无论项目做出何种决定，我们都鼓励定期测试其最新的依赖关系。
背景介绍
旧版指南确保库测试其最新的依赖关系，这有助于我们在 Rust 的软件包生态系统中保持高质量，确保问题（尤其是向后兼容性问题）被快速发现并解决。虽然这些额外的测试并不详尽，但我们相信这有助于在这个新生的生态系统中培养质量文化。
不过，这样做也不是没有弊端。这从代码库中删除了一段重要的历史，使得维护者更难分段查找错误的根本原因。对于贡献者（尤其是新贡献者）来说，每当依赖关系被删除或新版本包含错误时，不可靠的 CI 就会给他们带来另一种潜在的困惑和挫败感。
为什么要改变
自编写该指南以来，Rust 已经发生了很大变化。Rust 已从早期采用者的语言转变为更主流的语言，我们需要注意这些新加入 Rust 的开发者的入门体验。此外，随着采用范围的扩大，假设每个人都在使用最新的 Rust 版本并不总是切实可行的，因此社区一直在研究如何管理对最低支持 Rust 版本（MSRV）的支持。其中一部分工作就是维护依赖树的实例，使其能够与 MSRV 一起构建。锁定文件（lockfile）是为项目锁定版本的适当方式，这样您就可以验证 MSRV，但我们发现，由于我们之前指南的强度，人们反而对版本要求设置了上限，尽管这可能是一个更糟糕的解决方案。
在此期间，更广泛的软件开发生态系统也发生了很大变化。CI变得更容易设置和维护。我们还拥有了 Dependabot 和 Renovate 等产品。这除了让版本控制忽略 Cargo.lock 之外，还为测试更新的依赖关系提供了更多选择。开发人员可以安排一个计划任务，首先运行货物更新。开发人员还可以让机器人定期更新 PR 中的 Cargo.lock，确保它们在合并前通过 CI。
由于这些情况并没有通用的答案，因此我们认为最好让开发者自己做出选择，并为他们提供做出决定所需的信息。有关此政策变更的反馈，请参见 rust-lang/cargo#8728。你也可以在 Zulip 上联系 Cargo 团队。
转自 Change in Guidance on Committing Lockfiles | Rust Blog (rust-lang.org)