dist: bump rustup version to 1.27.0

[rami3l]

cc #3501.

Concerns

• Should we make a beta-driving phase for this?

---

Changelog

1.27.0 - 2024-03-08

This long-awaited Rustup release has gathered all the new features and fixes since April 2023.
These changes include improvements in Rustup's maintainability, user experience, compatibility and documentation quality.

The headlines of this release are:

• Basic support for fish shell has been added.
• Support for the loongarch64-unknown-linux-gnu host platform has been added.

Also, it's worth mentioning that Dirkjan Ochtman and rami3l have joined the team and are coordinating this new release.

Finally, the project seems to have attracted a total of 23 new contributors within this release cycle. Looking forward to seeing you again in the future!

Added

• Add basic support for fish shell pr#3108
• Add the RUSTUP_TERM_COLOR environment variable to force the use of colored output pr#3435
• Improve rustup-init.sh's compatibility with ksh and zsh pr#3475
• Add a warning when running under Rosetta 2 pr#3068
• Add browser detection for RISC-V 64 platform pr#3642
• Add a warning when removing the last/host target for a toolchain pr#3637

Changed

• Upgrade clap to v4 pr#3444
• Fix incorrect platform detection on macOS aarch64 due to Rosetta 2 pr#3438
• Fix incorrect platform detection on 32-bit Linux userland with a 64-bit kernel pr#3488 pr#3490
• Improve Windows system32 DLL loading mechanism pr#3493
• Improve suggestions about missing components pr#3453
• Fix handling of toolchain names with special characters pr#3518
• Fix panic in component list --toolchain stable pr#3548
• Rename llvm-tools-preview component to llvm-tools pr#3578
• Try using symlinks if possible on Windows pr#3687
• Bump a lot of dependencies to their latest versions pr#renovate-bot

Thanks go to:

• Anthony Perkins (acperkins)
• Tianqi (airstone42)
• Alex Gaynor (alex)
• Alex Hudspith (alexhudspith)
• Alan Somers (asomers)
• Brett (brettearle)
• Burak Emir (burakemir)
• Chris Denton (ChrisDenton)
• cui fliter (cuishuang)
• Dirkjan Ochtman (djc)
• Dezhi Wu (dzvon)
• Eric Swanson (ericswanson-dfinity)
• Prikshit Gautam (gautamprikshit1)
• hev (heiher)
• 二手掉包工程师 (hi-rustin)
• Kamila Borowska (KamilaBorowska)
• klensy (klensy)
• Jakub Beránek (Kobzol)
• Kornel (kornelski)
• Matt Harding (majaha)
• Mathias Brossard (mbrossard)
• Christian Thackston (nan60)
• Ruohui Wang (noirgif)
• Olivier Lemasle (olivierlemasle)
• Chih Wang (ongchi)
• Pavel Roskin (proski)
• rami3l (rami3l)
• Robert Collins (rbtcollins)
• Sandesh Pyakurel (Sandesh-Pyakurel)
• Waffle Maybe (WaffleLapkin)
• Jubilee (workingjubilee)
• WÁNG Xuěruì (xen0n)
• Yerkebulan Tulibergenov (yerke)
• Renovate Bot (renovate)

Full Changelog: 1.26.0...1.27.0

[hi-rustin]

Thanks for working on this! https://rust-lang.github.io/rustup/dev-guide/release-process.html Just a reminder:

1. We should merge the master's changes to stable.
2. We need to bump the versions and add a changelog on stable. (I usually create a PR target to stable, once all CI is green, I will push it from local, and then GitHub will automatically close the PR).
3. After we ask the t-release team to deliver the binaries, then we can merge the stable branch back to the master branch. (version bump + changelogs will merge back).

I guess the point is we need to release it based on the stable branch.

Thanks again! Very excited to see rustup 1.27.0.

[rami3l]

@hi-rustin Oops, looks like now stable and master are (and might always be) one commit off?

... or is it possible to force-push master to stable?

(cc @kinnison)

[hi-rustin]

@rami3l Can we merge that commit back to master?

[rami3l]

@rami3l Can we merge that commit back to master?

@hi-rustin I guess that might not be easy since I've made #3491 when I wasn't aware of the stable branch...

[hi-rustin]

@rami3l Can we merge that commit back to master?

@hi-rustin I guess that might not be easy since I've made #3491 when I wasn't aware of the stable branch...

How about we revert this PR? Then maybe we can merge stable back? (I am not very sure). We need to do some tests in our local repo.

[rami3l]

How about we revert this PR? Then maybe we can merge stable back? (I am not very sure). We need to do some tests in our local repo.

@hi-rustin Rather, I meant that I'm not very sure if our branch protection rules allow me to force-push on stable. According to my understanding it will work if it's allowed by the organization... That being said, don't worry. I believe we can find a solution.

---

Update: Just asked infra, it turns out there are currently no restrictions on that. I'll try that then. (Sorry for overwriting your commit!)

[kinnison]

Generally speaking (a) you should always merge back to master whatever ended up on stable after a release and (b) if stable does end up out-of-sync you need to carefully unpick what/why because it's the commit SHAs on stable which end up in release binaries so you don't want to lose them if at all possible.

[kinnison]

Otherwise, congratulations on this release, it looks like an excellent combination of features and fixes.

[rami3l]

Generally speaking (a) you should always merge back to master whatever ended up on stable after a release and (b) if stable does end up out-of-sync you need to carefully unpick what/why because it's the commit SHAs on stable which end up in release binaries so you don't want to lose them if at all possible.

@kinnison Thanks for the info! I checked again and I believe this change has been covered by #3491.

dist/release-1-27...stable gives:

Also, according to the current diff, the latest stable checksum to date is 577bf51ae 2023-04-05 which I believe is unrelated to this change made one month later.

[hi-rustin]

@rami3l I think there are two solutions for this issue.

1. Force push master to the stable. But we need to make sure we don't change any commit SHA before the 1.26.0 tag.
2. We can try to revert 1.26.0 should not be unreleased in the changelog #3491, and then try to merge stable to the master first(Need some local repo tests before we do it). Then we can merge the master to stable and start the release process on the stable branch.

I will run some quick tests for the second solution. If it works, then we won't need to do a force push.

[hi-rustin]

I tested soultion2 in my forked repo:

1. revert the PR 3491 in this PR: Revert "1.26.0 should not be unreleased in the changelog" hi-rustin/rustup#1
2. Create a PR from stable to master: Update release date hi-rustin/rustup#2
3. Create a PR from master to stable: Merge master to stable hi-rustin/rustup#3

It seemed to work well. Sorry again for forgetting to merge that commit back.

I will let the team make the decision! Thanks again for working on this!

[rami3l]

I tested soultion2 in my forked repo:
...
It seemed to work well. Sorry again for forgetting to merge that commit back.

I will let the team make the decision! Thanks again for working on this!

@hi-rustin Thanks again for trying it out!

However it still looks problematic in our case since GitHub Merge Queue is in action now and I guess that might change the shasums on step 2 anyway (unless I can still merge manually just for the release, I'm not quite sure about that). We have full control over the stable branch though so we can be sure that it is indeed in sync with master, but not in the opposite direction. Further discussions with infra might be required to move this forward... 🙇

[hi-rustin]

However it still looks problematic in our case since GitHub Merge Queue is in action now and I guess that might change the shasums on step 2 anyway (unless I can still merge manually just for the release, I'm not quite sure about that).

I see, we are using the rebase merge method now. But I guess this would also cause a problem when we want to merge the stable back to the master after we release 1.27.0.

[rami3l]

I see, we are using the rebase merge method now. But I guess this would also cause a problem when we want to merge the stable back to the master after we release 1.27.0.

Exactly, so IMHO we shouldn't. More precisely, from now on master should always be ahead of stable, and we can sync stable with master from time to time.

The only subtlety remaining seems to be the commit shasum in the release:

... we seem to have two different ones for the last release already:

1. The shasum in rustup.exe --help: 5af9b9484 2023-04-05
2. The shasum in rustup-init.sh --help: 577bf51ae 2023-04-05

In conclusion, with the new merge-queue-enabled workflow, if we still do the release in one PR:

• 1 and 2 still exist and remain traceable, and they will be different as in 1.26.
• 2 won't be found on stable, since it's been rewritten when being merged to master (but still traceable just like fb7b525).

There is even a way of making 2 accessible on stable as well, which is making two subsequent PRs, with the second pointing rustup-init.sh --help to a certain commit on master, but 1 and 2 will still be different in this case.
Better yet, we might be able to perform a fast-forward manually in order to prevent shasum changes if possible.

[hi-rustin]

we seem to have two different ones for the last release already:

I believe this is by design. You can find it in https://rust-lang.github.io/rustup/dev-guide/release-process.html.

Because we need to update the Cargo.lock and push it first. After that, we can get the commit for updating the Cargo.lock.

After we finally build the binary and release it, then we get the different commits for them.

For instance:

1. The 1.25.1 init.sh sha:

   rustup/rustup-init.sh

   Line 28 in bb60b1e

   rustup-init 1.25.1 (48d233f65 2022-07-12)

   rustup-init 1.25.1 (48d233f 2022-07-12)
2. The 1.25.1 tag sha: bb60b1e

[rami3l]

In that case, I guess we can try to initiate the release process.
First, this PR will be merged to master; then the changes will be reflected on stable.

Next, since this is the first release since such a long time, I propose doing a beta-testing phase by (quoting @kinnison)

getting as far as the release would normally on the stable branch and the dev-static.rlo push from t-release; then you stop, and do the extra testing.

I expect to keep it like that without actually releasing for a few weeks.
Hopefully this will buy us some time in order to decide whether to revert #3578, for example.

Thus, I'm marking this PR as ready again.

[rami3l]

Note: As we have decided to include a beta-testing phase, merging this PR doesn't imply a new release (yet), so #3501 won't be closed for now.

However, we sincerely invite everyone in this thread to try out the beta by setting the following env variable:

RUSTUP_UPDATE_ROOT=https://dev-static.rust-lang.org/rustup

The actual beta release will be available shortly after the stable branch's CI turns green. Please stay tuned! The beta release seems to be available right now. If you don't mind, please try it out and let us know what you think about it! :)

Here's the relevant internals forum thread: https://internals.rust-lang.org/t/seeking-beta-testers-for-rustup-1-27-0/20352