Cargo.lock contains project's own version, unnecessarily

In Cargo.lock there's a [[package]] entry for the project itself (workspace members, technically), and like all entries, it contains a version field.

If I bump the version in Cargo.toml, the Cargo.lock version becomes out of sync, and that causes some annoyances for a project that keeps Cargo.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 the version field from packages in Cargo.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(), when EncodableDependency is in the workspace, use the version from the ws.members() instead.

Does that make sense? Would that work? Would you accept such change?

Start in EncodableResolve::into_resolve(), focusing on how EncodableDependency entries for workspace members are generated and how ws.members() is used. Compare the resulting Cargo.lock entry with Cargo.toml version changes, then determine whether omitting the workspace-member version or using a constant preserves compatibility; done means version bumps no longer cause unrelated lockfile updates.