多年来，Cargo 团队一直鼓励 Rust 开发人员 将包含二进制文件的包的 Cargo.lock 文件提交到版本控制，但库除外。我们现在建议人们 选择最适合其项目的做法。为了帮助人们做出决定，我们确实提供了一些考虑因素，并建议将 Cargo.lock 作为决策过程的起点。为了与该起点保持一致，从 nightly-2023-08-24 开始，cargo new 将不再忽略库的 Cargo.lock。无论项目做出何种决定，我们都鼓励定期 针对最新依赖项进行测试。

背景

旧的指南确保库测试其最新的依赖项，这有助于我们通过确保快速发现和解决问题（尤其是向后兼容性问题）来保持 Rust 包生态系统的质量。虽然这种额外的测试并不详尽，但我们相信它有助于在这一新兴生态系统中培养一种质量文化。

但这并非没有缺点。这从代码库中删除了重要的历史记录，使维护人员更难进行二分查找以找到错误的根本原因。对于贡献者，尤其是新手来说，当依赖项被撤回或新版本包含错误时，这是另一个可能导致 CI 不可靠并引发困惑和沮丧的潜在来源。

为什么改变

自编写指南以来，Rust 发生了很大变化。Rust 已从面向早期采用者的语言转变为更主流的语言，我们需要关注这些 Rust 新手的入门体验。此外，随着这种更广泛的采用，并不总是可以实际地假设每个人都在使用最新的 Rust 版本，并且社区一直在努力解决如何管理对最低支持 Rust 版本 (MSRV) 的支持。其中一部分是维护一个可以与您的 MSRV 构建的依赖项树实例。锁定文件是为您的项目固定版本的合适方法，这样您就可以验证您的 MSRV，但我们发现人们反而在版本要求中设置了上限，因为我们之前的指南非常严格，尽管 这可能是一个更糟糕的解决方案。

在此期间，更广泛的软件开发生态系统也发生了很大变化。CI 的设置和维护变得更加容易。我们还有像 Dependabot 和 Renovate 这样的产品。这为测试更新的依赖项提供了除版本控制忽略 Cargo.lock 之外的选择。开发人员可以安排一个定期运行 cargo update 的作业。他们还可以让机器人定期在 PR 中更新他们的 Cargo.lock，确保它们在合并之前通过 CI。

由于这些情况没有普遍的答案，我们认为最好将选择权留给开发人员，并为他们提供做出决定的必要信息。有关此策略变更的反馈，请参阅 rust-lang/cargo#8728。您也可以在 Zulip 上更广泛地联系 Cargo 团队。