-
Notifications
You must be signed in to change notification settings - Fork 965
Cargo.lock strategy #1230
Description
The current recommendation is to not commit Cargo.lock for libraries but commit it for binaries. The main reason being that it doesn't affect downstream crates. However I think that committing it has some value - it says "we tested this crate with these versions of dependencies". And if we review the crates (ensuring the hashes match) it also acts as a lightweight cargo-crev. (I myself don't want to commit to this for now, maybe around 1.0 where versions will be more stable.)
However we could have these problems: people accidentally changing and committing it possibly causing merge conflicts, older versions of crates not being recorded.
As a solution I propose having Cargo-minimal.lock and Cargo-recent.lock. CI will just copy them over Cargo.lock before run.
Cargo-minimal.lock would contain minimal versions (See #1229 ) and would be only updated when we update Cargo.toml (We can probably have a check for this.) Cargo-recent.lock could be updated more often but always in a distinct PR to not cause merge conflicts.