add note to cargo install --help that says cargo install --vers x.x.x requires =x.x.x to install specific version

[ducks]

From cargo install --help:

"Crates from crates.io can optionally specify the version they wish to install
via the --vers VERS flags,"

Make a note that VERS needs to be in the format =x.x.x (equal before version)

[steveklabnik]

That is, VERS is a semver version range, not an exact version.

[alexcrichton]

Hm this was intended to be a precise semver version. If we made a mistake and took a range though I guess that ship has sailed...

[steveklabnik]

@alexcrichton we should double check the behavior but this is what @ducks observed in IRC.

[ducks]

https://gist.github.com/ducks/12fd804600469a888b4d32c251a44f03

running without the =/range, cargo just seemed to ignore the version
https://gist.github.com/ducks/12fd804600469a888b4d32c251a44f03#file-gistfile1-txt-L23

[alexcrichton]

Yes this was accidentally implemented as a version requirement, not a version itself. Oh well :(

[sfackler]

It seems like this is a thing we should just fix? As long as we can have some kind of nice error message if you try to give it a version requirement it seems fine to do.

[alexcrichton]

I've opened #3338 to fix this behavior.

[azerupi]

I actually have a use case for installing a binary using a semver range.
mdBook is used to render some of the books for Rust and other projects in the community and we sometimes have to issue a breaking release. However, since books are often automatically deployed through CI, we don't want to break all the guides when we push a breaking release. So we have to advise users to pin the version of mdBook in their deployment scripts.

If we had semver ranges for binaries, CI scripts could automatically install the latest non-breaking version, benefiting from all the improvements without the risk of breakage. This would reduce manual intervention to only breaking releases instead of every point release.

I know this feature still works, so technically I could tell users to use it. But I don't want to push the use of a deprecated feature that could disappear in the future. Do you think this is a valid argument to consider undeprecating this feature?

[alexcrichton]

@azerupi it seems reasonable to me, yeah! I think we'd just want a new flag for this, like cargo install --range ... because --vers sounds too much like "I want this precise version"

[azerupi]

I think we'd just want a new flag for this, like cargo install --range ...

Sure, that makes a lot of sense!
Should I create a new issue to track and discuss this? Also I wouldn't mind trying to make a PR for this if it a desirable feature. :)

[alexcrichton]

Sure yeah a new issue sounds good, and a PR sounds even better!