`rustup -V` outputs strange version number

[brson]

Describe the problem you are trying to solve

rustup -V outputs rustup 1.18.0 :: 1.17.0+179 (8603e2c56 2019-04-22) dirty 1 modification.

I do not understand what the " :: 1.17.0+179" and "dirty 1 modification" strings mean. I am confused and worried about the state of my installation.

Describe the solution you'd like

The tool's output should be self-explanatory.

[kinnison]

This version form means that the Cargo.toml says 1.18.0 but the git tags say 1.17.0 and you have 179 commits since then, and 1 in-tree modification (added, changed, deleted, or untracked file)

How did you get the rustup you are running? Release rustup should give a very clean version number because of our CI build process.

If you're running your own version of rustup or you have a repo which doesn't have the tags in it, then that'd explain things a little.

Users should normally only ever see a clean "x.y.z (9charsha date)" version string.

[tesuji]

I would suggest adding a FAQ in README about this rustup -V output.

[kinnison]

I'm not convinced about README.md, but perhaps CONTRIBUTING.md instead?

In my mind, README.md is more for users of the tool, who should never end up with tools whose version string looks like that. Any user who's being asked to beta-test a newer version will be told about it directly, and that'd be the responsibility of the wg-rustup member who was asking them to, hence CONTRIBUTING.md.

[JasonWeise]

I have just installed rust on Windows 10 with the rustup-init.exe installer from the Rust homepage (literally just now).

When I run rustup -V I get the following output as well:
rustup 1.18.1 :: 1.18.0+20 (462683b3a 2019-04-25) dirty 1 modification

Is there a way for me to update rustup so it is showing as clean?

[kinnison]

Thanks @JasonWeise - I'm guessing that our appveyor builds are somehow dirtying the git repository. The version code deliberately refuses to hide that, even on releases, hence the very odd looking version number. @brson I apologise, I had assumed you were doing some kind of build because the other platforms seem to report version numbers just fine on our stable builds.

I stand by my assertion that these complex version displays should not be on release builds, so this is definitely a bug, I will investigate now.

[kinnison]

Okay, I've determined what went wrong with our appveyor builds and have filed #1822 to deal with it. I won't consider this closed though until I've written up something in CONTRIBUTING.md too though.

Thank you both for reporting this. I simply didn't consider that appveyor builds wouldn't be clean 😢

[JasonWeise]

@kinnison good stuff.
Thanks for the speedy investigation.
I had never noticed it before I saw @brson post but when installing onto my new laptop today found the above results and thought it odd.

Thanks again!

[kinnison]

It's partly my fault - I do have a tendency to treat Windows as a third-class citizen behind MacOS behind Linux :D 1.18.2 should have this fixed when I release it later this week.

[kinnison]

1.18.2 has been released which should resolve this for the most part, but I will still need to write a CONTRIBUTING.md statement about the shape of version numbers too. So I'll hold this open until that is done.

[rbtcollins]

@kinnison I think this is closable now. I'm so sure that I'm going to and you can reopen if I'm wrong.