多年来，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 团队。