Downloading specific betas should be easier

[glandium]

For Firefox, we have a script that kind of duplicates the behavior of rustup and that repacks rust for use on Firefox CI. In some cases, we need to pin a specific beta version, but failed to do so, so when 1.24.0-beta.1 replaced 1.23.0-beta.2 today, we ended up picking that, which, incidentally, broke Firefox CI because 1.24.0-beta.1 apparently breaks slog and servo.

Anyways, after some fiddling, it came out that it's possible to get a specific beta version... if you know when it was released.

That is,

$ rustup toolchain install beta-2017-12-08

installs 1.23.0-beta.2. You have to know that 1.23.0-beta.2 was released on that specific day, or scan all dates.

It would be much easier if it were possible to do:

$ rustup toolchain install 1.23.0-beta.2

which could rely on an hypothetical https://static.rust-lang.org/dist/channel-rust-1.23.0-beta.2.toml file.

[glandium]

To add insult to injury, beta-2020-11-18 is 1.49.0-beta.1 (21dea46d8 2020-11-18), but beta-2020-11-26 is 1.49.0-beta.2 (bd26e4e54 2020-11-24), so you can't even pull the latest beta and get the date from rustc --version.

[kinnison]

To be fair to rustup this is a side-effect of the way channels are constructed during builds of rust-lang/rust. If you want to ameliorate this, it may be better to talk with a t-release member about how beta channels are constructed and when, and how making them more predictable might be done.

[sffc]

Are there any tips to figure out the date for a certain beta version, like 1.56.0-beta.3 ?

[kinnison]

Sadly, short of having the Rust release process create version numbered beta release manifests, there's not a lot we can do from the Rustup side :/

[kit-981]

Sadly, short of having the Rust release process create version numbered beta release manifests, there's not a lot we can do from the Rustup side :/

Is there a place where this change can be proposed and discussed?

The release format described at https://forge.rust-lang.org/infra/channel-layout.html does not seem straightforward to me and it's unsurprising that it's difficult to find toolchains using their identifier. It's unclear to me why toolchains are not simply stored under /dist in directories such as stable-1.60.0+1, beta-1.61.0+2, and nightly-2022.04.14+1 that clearly identify the toolchain. This doesn't omit the date information either because that is present in the manifest.

[kinnison]

Thinking more about this, we'd have to add support for the channel names in rustup too, but I've opened a Zulip thread to discuss how this might work.

https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/version-numbered.20beta.20channels

[Mark-Simulacrum]

We discussed this briefly over Zulip and it sounds feasible. I think the next step here is likely to land the code to do this upstream in our release promotion (around https://github.com/rust-lang/rust/blob/master/src/tools/build-manifest/src/main.rs#L247), and then work with @kinnison to figure out what's necessary to get rustup to support parsing the CLI parameter.

[RivenSkaye]

You could also fetch the current beta version at the point in time where you pin it for CI and write that into rust-toolchain.toml. I referenced this issue elsewhere, and the resources provided here got me a nice curl + GNU Grep oneliner for pinning down what release date to install. If GNU Grep isn't an option, there's almost definitely some awk equivalent to be used though.

[Skgland]

Sadly, short of having the Rust release process create version numbered beta release manifests, there's not a lot we can do from the Rustup side :/

The manifests now exists since about 1.75 beta. e.g. https://static.rust-lang.org/dist/channel-rust-1.75.0-beta.1.toml

[roife]

@rustbot claim