Update TRPL/Installing Rust to avoid concrete version numbers

[dcarral]

Update "Installing Rust" section @ TRPL so it references the last stable version, v1.3.0.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[steveklabnik]

Thanks! The problem here is that master is currently 1.5, so this is going to introduce a bug :) Would you mind updating it for that, please?

(and there's a problem here, that we don't know what the actual date/hash is going to be, and can't...)

[leoyvens]

This should be part of the release process?

[dcarral]

Thanks for the prompt review Steve ;)

I don't agree in updating it to v1.5 (even if we'd be able to know the date/hash). I mean, currently, when readers follow the installation instructions indicated in the book, they end up with the current stable release, which is v1.3.0. Therefore I think it makes complete sense to update the text to v1.3.0 then.

Obviously, once the next version is released, the text should be updated again. If this could be part of the release process, as @leodasvacas points out, there won't be the need for manual updates ;)

[steveklabnik]

@dcarrell if this PR is merged right now, due to the way the release process works, 1.5 is the first release this patch will be in. 1.3 is already out, and 1.4 has already been forked for beta, and we very, very rarely do documentation back ports.

@leodasvacas we can't know the git hash before this text is written, because the content of the text is involved creating the hash... Know what I mean? This text was always supposed to be "it should look like this" not "it should be exactly this" for this reason.

[dcarral]

That makes complete sense Steve. I (naively) thought that the book showed the contents present in the master branch.

Thanks for the info then and obviously feel free to safely close this PR.

[leoyvens]

@steveklabnik I see. But keeping the version number up to date would be good.

[steveklabnik]

Right. There's certainly a pain point here, I'm just not sure how best to handle it. Do either of you have thoughts? Can we use vaguer wording here, or maybe just elide the exact hash?

No need to close the PR, we can just update it :)

[brson]

IMO 1.3 is more correct so its better than what we've got, but we can prob do better. Getting the hash for the stable release in the stable docs isn't possible without moving docs out of tree (which we might ought consider).

I think a reasonable compromise would be to write 1.5 and ellide the hash.

[leoyvens]

Referring to an old version gives an undeserved impression that the document is out-of-date. Also the example is less reassuring if it dosen't match exactly what is shown. Maybe it's best to remove the example and just say You should see the version number, commit hash, and commit date. If you do, Rust has been installed successfully! Congrats!. Even a novice user will be able to tell the correct message from an error message.

[dcarral]

The option which I like the most is what @leodasvacas has proposed (remove the example and just include a vaguer wording), for the exact reasons he's pointed out.

@steveklabnik, @brson: Do you like the proposed wording or have any other inputs?

[steveklabnik]

I like it.

[nikomatsakis]

r=me, fwiw, but I'm happy to wait till @brson chimes in.

[steveklabnik]

I'm also happy, but would like to r? @brson

[brson]

@bors r+

[bors]

📌 Commit f5a653e has been approved by brson

[brson]

@bors rollup

[bors]

⌛ Testing commit f5a653e with merge a03e0ee...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt