Skip to content

Cargo.lock strategy #1230

@Kixunil

Description

@Kixunil

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions