docs: update channel toolchain syntax

[kyle-leonhard]

Update documentation to match https://rust-lang.github.io/rustup/concepts/toolchains.html

[kyle-leonhard]

@djc - can I ask you a quick question about the <major.minor> form? I worked a bit on getting renovate to bump versions in the channel entry in override files: renovatebot/renovate#32432.

Is it correct that <major.minor> indicates compatibility with any patch version and will resolve to the latest patch version?

For example, 1.80 will resolve to 1.80.1 and not 1.80.0.

[djc]

I think how it works in rustup is that rust toolchain add 1.80 will install the latest 1.80.x at the time. I don't think that means the 1.80 install will get updated implicitly once 1.80.1 comes out.

[kyle-leonhard]

I think how it works in rustup is that rust toolchain add 1.80 will install the latest 1.80.x at the time. I don't think that means the 1.80 install will get updated implicitly once 1.80.1 comes out.

Thanks! Makes sense to me, it works like "stable" or "nightly" would but fixed to a particular minor version

[rami3l]

@kyle-leonhard Sorry for the existing issue, but even our TOOLCHAIN_HELP is out of date after #3858.

Now that we are here, would you mind updating both TOOLCHAIN_HELP and this file accordingly, maybe in a separate commit or two, by adding the following to the mix?

• 1.80-beta
• 1.80-beta.1 ¹
• 1.80.0-beta
• 1.80.0-beta.1

You may add sub-rules such as <versioned> = <major.minor>|<major.minor.patch> to simplify the writing.

Many thanks in advance!

Footnotes

1. Our parser accepts it, but it doesn't have a manifest² yet. I think it wouldn't cause that much of a problem since other forms are not guaranteed to have a manifest either. ↩

2. To complete the context, 1.80, for example, is the name of a certain manifest on the release server that can change from time to time. So on our side we just look for matching manifests on that server. If you are interested, you can refer to https://github.com/rust-lang/rust/pull/76107 for more details on this. ↩

[kyle-leonhard]

@rami3l I added beta tags to both the toolchain and overrides documentation and the cli help.

Can I take advantage of the goodwill to ask you a question? (feel free to reroute me). I was working on making renovate bump versions in the toolchain overrides file and a question came up: (pr).

Does the rust toolchain install directly from github releases? e.g. a second after a new release is published on github.com, it's possible to install it using rust toolchain?

Basically, it's convenient to use Github as a datasource for releases, to avoid doing the work to use the rust release servers. But it's important that releases being available on github mean the release is available for install. Does that make sense?

[rami3l]

@kyle-leonhard This is looking great!

There's just one small change before merging... Also, I think it's more reasonable to squash all these commits together and give it a proper message before it can be merged: something along the lines of docs: update channel toolchain syntax would be fine.

[rami3l]

Can I take advantage of the goodwill to ask you a question? (feel free to reroute me). I was working on making renovate bump versions in the toolchain overrides file and a question came up: (pr).

@kyle-leonhard Let's continue this discussion under renovatebot/renovate#32432 (comment).

[kyle-leonhard]

Thanks @rami3l. Made the updates and squashed the commits