Closes#945.
Based on @diziet's comment in #945, with a little extra safety and
paranoia. We use this for cases when there are trivial changes only
in one of our crates.
* Remove instructions to sleep
* Explain how to tag
* Remind myself about the workaround for
Fedora's delightful gpg/yubikey configuration.
* Note that we should update "pages" till the blog post is up.
I've split this into
"what I do in the days leading up to the release" and
"what I do right before the release".
There's a lot more detail now, including:
* up-to-date invocations for `cargo upgrade`
* up-to-date changelog instructions
* our current version-bumping instructions
* possible side-effects from version bumps.
* Remove references to a couple of things
that our CI now does for us
(`cargo_audit` and `check_licenses`).
* Mention ~Blocker issues and MRs.
* Mention that some of our CI steps are allowed-to-fail,
but failures should be examined.
* Mention that some of our tools have exception lists
that should get reviewed.
* Mention `semver-checks` and `fixup-features`.
We did roughly this today. We put the CHANGELOG.md change in its own
MR, so it didn't end up in the tor-llcrypto-v0.4.4 tag. It would have
been better to do it the other way so that's what I've documented.
I couldn't test-format this with pandoc because it got tricked by some
of the `$` into trying to run TeX.