Rather than encouraging Rust developers to commit their Cargo.lock file for packages with binaries but not libraries, Rust’s Cargo team now recommends developers do whatever is best for their project. The change in guidance, from the team behind the Rust package manager, is being made in light of the Rust language becoming more mainstream.
A Cargo.lock lockfile is intended to describe state at the time of a successful build. In recommending people do what is best for the project, the team still suggests committing Cargo.lock as the starting point of their decision making. The cargo new command will no longer ignore Cargo.lock for libraries.
The Cargo team encourages regular testing against latest dependencies. In a bulletin published August 29, the Cargo team said that the old guidelines ensured libraries tested their latest dependencies, helping to maintain high quality within Rust’s package ecosystem by ensuring issues, particularly backward compatibility, were quickly resolved. The team believed it helped promote a “culture of quality” in the nascent ecosystem.
But there have been downsides, such as removing history from the code bases, making bisecting to find the root cause of a bug more difficult for maintainers. And confusion could result for contributors, from an unreliable CI (continuous integration) when a dependency is removed or a new release has a bug. Since this guideline was written, Rust has moved from being a language for early adopters to being more mainstream; the on-boarding experience of new Rust developers must be kept in mind. Wider adoption also means it is not always practical to assume everyone is using the latest Rust release.
Further, the wider ecosystem has seen CI become easier to set up and maintain. Products such as Dependabot and Renovate have opened up options besides having version control ignore Cargo.lock to test new dependencies. The Cargo team now believes it is best to leave the choice to developers while giving them the information needed to make a decision. Developers can offer feedback on this policy on GitHub, or they can reach out to the Cargo team on Zulip.