Cargo upgrade behavior changes

Hi, I used cargo upgrade about two months ago to upgrade the dependency versions in the Cargo.toml of a project.

I recently upgraded to the latest cargo edit and performed another project wide upgrade. But the 'upgrade' feature seems to have changed behavior dramatically.

I used to simply run 'cargo upgrade' in a workspace and it would update all dep semvers in the Cargo.toml to the latest versions.

But now cargo upgrade is deciding to not upgrade the semver of a rep if it's compatible. Also some dependencies are classified as locked but what that means isn't explained anywhere.
It seems that the expected workflow is to use cargo update to update the lock file and then use cargo upgrade --to-lockfile to change the semver's of the deps in the Cargo.toml.

I don't see a clear explanation on the repo readme or in the commits of why these changes were made and what the expected workflow is now.

It seems to be that changes are being made so that 'cargo upgrade' can eventually be merged into cargo and coexist/merge with 'cargo update'

Can anyone shed some light on the recent changes to cargo-edit's upgrade feature and what the expected workflow is now?

Thanks

I don't use it and have absolutely no idea, but I imagine this IRLO thread has some explanation.

CC @epage (hope that's appropriate).

1 Like

Ah that conversation clears it up.

Most importantly:

At the moment, to get exactly the old behavior requires doing cargo update && cargo upgrade && cargo upgrade --to-lockfile.

Good timing as I just released the next experiment on the path for merging cargo upgrade into cargo.

See Release v0.11.0 · killercup/cargo-edit · GitHub for more details. Hopefully this will work out a lot better and be less confusing

And thanks @quinedot for looping me in as I don't normally follow users (too noisy for me)

1 Like