多年来，Cargo 团队一直鼓励 Rust 开发人员为包含二进制文件的包提交他们的 Cargo.lock 文件，但不为库提交。现在，我们建议人们根据项目的实际情况做出最佳选择。为了帮助人们做出决定，我们提供了一些考虑因素，并建议将提交 Cargo.lock 作为他们决策的起点。为了与该起点保持一致，从 nightly-2023-08-24 开始，cargo new 将不再忽略库的 Cargo.lock 文件。无论项目做出什么决定，我们都鼓励定期针对最新的依赖项进行测试。

背景

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

但这并非没有缺点。这从代码库中移除了一段重要的历史记录，使得维护人员更难通过二分查找来找到错误的根本原因。对于贡献者（尤其是新手）来说，当依赖项被撤销或新版本包含错误时，这又增加了一个潜在的混淆和 CI 不可靠的来源。

为什么改变

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

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

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