Old lock file format is never written anymore

[mathstuf]

Problem

It seems to no longer be possible to get the old lock file format written anymore. Running nightly toolchains which touch the file seem to update it causing me to have to nuke it (since we support and test older toolchains too).

This mainly affects my wish to test minimal versions where -Z minimal-versions forces it to use a newer toolchain which then blocks out testing with the older toolchain (to ensure compatibility).

Steps

1. cargo +1.32.0 update
2. cargo +nightly update -Z minimal-versions
3. echo "Cargo.lock no longer works with 1.32"

Possible Solution(s)

Support a flag to write out the old lock file format. It used to be auto-detecting and not upgrade, but that changed at some point.

Notes

Output of cargo version:

cargo 1.48.0-nightly (875e01232 2020-09-08)

[Eh2406]

Fyi, This was changed by #8554.

[est31]

Note that it's only updating the lock file format when there is an underlying semantic change in the Cargo.lock, at least that's the idea.

I understand your use case though, you have to use nightly. You could try using a pinned older nightly version, e.g. one one day before the PR #8554 was merged.

[ehuss]

We talked about this in the Cargo team meeting. I'm going to close, as I don't think we're going to add specific support for this. -Zminimal-versions is currently not recommended, as we don't feel it is going to be viable as-is, and Cargo does not have infinite forwards compatibility. Support for the new lock file format was added in 1.38 which provides over a year of compatibility.

I would suggest if you want to continue using -Zminimal-versions, to test that with a newer version (like 1.38 or newer). Or, you can always use a pinned nightly that generates the old format.

[Eh2406]

The third party cargo-lock crate may be another alternative. https://docs.rs/cargo-lock/5.0.0/cargo_lock/index.html#translate-convert-cargolock-files-between-the-v1-and-v2-formats