Closed Jeppelelle closed 1 year ago
cargo-upgrade intentionally preserves the users version requirement syntax, upgrading within that.
If you don't want wildcard dependencies, it isn't cargo-upgrades responsibility to fix that. It instead trusts you in what you did. Remove wildcards and it will work as expected.
Expected behavior of cargo upgrade, atleast in my opinion is to always insert the version numbers into all dependencies when running
cargo upgrade
, or to specified dependencies using -pIf i have etc stringmetrics as a dep:
[dependencies] stringmetrics = "2.2.0"
After running
cargo upgrade
:[dependencies] stringmetrics = "2.2.2"
Doing the same with "*" if i already have the latest version of a dependency will leave the toml as follows:
[dependencies] stringmetrics = "*"
Thus there is no parity of Cargo.toml using the
cargo upgrade
commandcargo upgrade
leaving Cargo.toml in various states is not optimal, if stringmetrics happens to update AFTER i run the command and compile my project with cargo, it may download a newer version which is NOT what one should expect, there is a reason why we add specified hardcoded depenency versions in our Cargo.toml AND upgrade our deps to newer versions when we want or are ready to upgrade a dep