Cargo.lock contains project's own version, unnecessarily #5979
Labels
A-lockfile
Area: Cargo.lock issues
C-feature-request
Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
S-needs-team-input
Status: Needs input from team on whether/how to proceed.
In
Cargo.lock
there's a[[package]]
entry for the project itself (workspace members, technically), and like all entries, it contains aversion
field.If I bump the version in
Cargo.toml
, theCargo.lock
version becomes out of sync, and that causes some annoyances for a project that keepsCargo.lock
under version control:When I bump the project version, I have to remember to also run some lock-rewriting Cargo command to update the lockfile version, even if I don't intend to update any dependencies. This feels like an unnecessary step to be mindful of.
OTOH, if I don't update the lockfile at the same time when bumping the version, some future operation will. This causes an unwanted/unrelated change in a later commit in the project.
Fortunately, it looks like the version in
Cargo.toml
is not actually used for anything important. Ideally, I'd like to completely remove theversion
field from packages inCargo.lock
that are workspace members, but for better backwards compatibility, the version could be locked to some constant value (e.g.0.0.0-workspace
).Technically it seems possible: in
EncodableResolve::into_resolve()
, whenEncodableDependency
is in the workspace, use the version from thews.members()
instead.Does that make sense? Would that work? Would you accept such change?
The text was updated successfully, but these errors were encountered: