Today marks the release of
rustup version 1.17.0 which
is both the first version of
rustup which I have contributed code to, and
also the first version which I was responsible for preparing the release of.
I thought I ought to detail the experience, but first, a little background…
At the end of last year, leading into this year, I made some plans which included an explicit statement to "give back" to the Rust community as I'd received a lot of help with, and enjoyment in, Rust from the community over the previous couple of years. I looked for ways I could contribute, including making a tiny wording PR against the compiler which I won't even bother linking here, but eventually I decided to try and help with the rust-lang/rustup.rs repository and tried to tackle some of the issues therein.
Nick Cameron was, at the time, about to step down as a lead of the tools team and he ended up talking to me about maybe joining a working group to look after Rustup. I agreed and a little earlier this year, I became part of the Rustup working group, which is a sub-group of the Cargo team, part of the Rust developer tools teams.
Over the past few weeks we've been preparing a new release of Rustup to include some useful bug fixes and a few little feature tweaks. Rustup is not as glamorous a part of the ecosystem as perhaps Cargo or Rustc itself, but it's just as important I think, since it's the primary gateway through which people acquire Rust, and interact with the Rust toolchain ecosystem.
On Tuesday evening, as part of our weekly meeting, we discussed the 1.17.0 release plans and process, and since I'm very bad at stepping back at the right moment, I ended up volunteering to run the release checklist through and push 1.17.0 out of the door. Thankfully, between Nick and Alex Crichton we had a good set of instructions and so I set about making the release. I prepared a nice series of commits updating the version numbers, ensuring the lock file was up to date, making the shell script installer frontend include the right version numbers, and pushed them off to be built by the CI. Unfortunately a break in a library we depend on, which only showed its face on our mingw builders (not normally part of the CI since there are so few available to the org) meant that I had to reissue the build and go to bed.
Note that I said I had to go to bed - this was nearing midnight and I was due up before 7am the following day. This might give you some impression of the state of mind I was in trying to do this release and thus perhaps a hint of where I'm going to be going with this post…
In the morning, I checked and the CI pipelines had gone green, so I waited until Alex showed up (since he was on UTC-6) and as soon as I spotted him online, around 14:45 UTC, I pinged him and he pushed the button to prep the release after we did a final check that things looked okay together. The release went live at 14:47 UTC.
And by 15:00 UTC we'd found a previously unnoticed bug - in the shell installer frontend - that I had definitely tested the night before. A "that can't possibly have ever worked" kind of bug which was breaking any CI job which downloaded rustup from scratch. Alex deployed a hotfix straight to the dist server at 15:06 UTC to ensure that as few people as possible encountered the issue, though we did get one bug report (filed a smidge later at 15:15 UTC) about it.
By this point I was frantic - I KNEW that I'd tested this code, so how on earth was it broken? I went rummaging back through the shell history on the system where I'd done the testing, reconstructing the previous night's fevered testing process and eventually discovered what had gone wrong. I'd been diffing the 1.16.0 and 1.17.0 releases and had somehow managed to test the OLD shell frontend rather than the new one. So the change to it which broke the world hadn't been noticed by me at that point.
I sorted a fix PR out and we now have some issues open regarding ensuring that this never happens again. But what can we do to ensure that the next release goes more smoothly? For one, we need as a team to work out how to run mingw tests more regularly, and ideally on the PRs. For two, we need to work out how we can better test, the shell frontend which is currently only manually verified, under CI when its sole purpose is to download rustup from the Internet, making it a bit of a pain to verify in a CI environment.
But… we will learn, we will grow, and we won't make these mistakes again. I had been as careful as I thought I could be in preparing 1.17.0, and I still had two painful spikes, one from uncommonly run CI, and one from untested code. No matter how careful one is, one can still be bitten by things.
On a lighter note, for those who use
rustup and wonder what's in 1.17.0 over
the previous (1.16.0) release, here's a simplified view onto a mere subset of
- Better formatting of long download times. Manish Goregaokar
- Various improvements to
rustup-init.sh. Lzu Tao
- A variety of error message improvements. Hirokazu Hata
- Prevent panic on missing components. Nick Cameron
- Support non-utf8 arguments in proxies. Andy Russell
- More support for
homebrew. Markus Reiter
- Support for more documents in
rustup doc. Wang Kong
- Display progress during component unpack. Daniel Silverstone
- Don't panic on bad
default-host. Daniel Silverstone
- A variety of code cleanups and fixes. So many of them. Dale Wijnand
- Better error reporting for missing binaries. Alik Aslanyan
- Documentation of, and testing for, powershell completions. Matt Gucci
- Various improvements to display of information in things like
rustup status. Trevor Miranda
- Ignoring of
EPIPEin certain circumstances to improve scripting use of
rustup. Niklas Claesson
- Deprecating cURL in
downloadinternal crate. Trevor Miranda
- Error message improvements wrt. unavailable components. Daniel Silverstone
- Improvements in component listing API for better automation. Naftuli Kay
If I missed your commits out, it doesn't mean I thought they weren't important, it merely means I am lazy
As you can see, we had a nice selection of contributors, from Rustup WG members, to drive-by typo fixes (unlisted for the most part) to some excellent new contributors who are being more and more involved as time passes.
We have plenty of plans for 1.18.0, mostly centered around tidying up the
codebase more, getting rid of legacies in the code where we can, and making
it easier to see the wood for the trees as we bring
rustup up-to-snuff as
a modern part of the Rust ecosystem.
If you'd like to participate in Rustup development, why not join us on our
discord server? You can visit https://discord.gg/rust-lang and once you've
jumped through some of the anti-spam hoops (check your DMs on joining) you can
come along to
#wg-rustup and we'll be pleased to have you help. Failing
that, you can always just open issues or PRs on
https://github.com/rust-lang/rustup.rs if you have something useful to