-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo upgrade reports 2.0 -> 2.0.0 as an upgrade #516
Comments
Thanks for reporting this! |
This might be tricky to solve. The same behaviour occurs when you try it with Lines 73 to 76 in f6706af
The semver::Version struct requires all major minor and patch fields to be filled so when that is constructed it just fills them with 0. By the time we're merging the new and old dependencies in Line 70 in f6706af
--skip-compatibility flag is added. thoughts?
|
note: this is going to meander as I explore ideas I've run into something similar with
For "make compatible" and "upgrade to latest", we use the exact same requirement syntax as the user and just update the relevant fields. Say we are upgrading a For now, With
Some questions for resolving this Issue:
|
I'm going to keep thinking about the correct behaviour for a bit, but I did notice one thing during the investigating I did for this issue and that is in the case of Continuing on that thought, I think that one common interface that might be useful is a more structured validation of the satisfactory versions. Right now it's kind of happening in-place since previously only things like |
We do this today for |
My cargo.toml previously contained:
This seems harmless, but it's a little confusing.
The text was updated successfully, but these errors were encountered: