Rust crate release checklist

Previously on #rust:

• Things I learned writing an SSDP implementation in Rust
• Self-hosted CI for Rust and C++ using Laminar

There’s been a few public releases now of the Rust crates I’ve been working on, cotton-netif and cotton-ssdp. The SSDP one even has a merged pull request from a contributor! But because it’s often a little while between releases, I struggle to remember all the steps required. (Not so many, as Cotton is no massive failer of the Joel Test, but there are a few moving parts just because of all the fine, free open-source tools in use.) This document collects them all in one place, as much for my own benefit as anyone else’s.

1. Check Github for third-party pull requests as I don’t want to annoy contributors by seeming to ignore their work. This check can be automated using a badge:
2. Update Cargo.toml and CHANGELOG.md for all packages being released, like in commit 4ba3675c. If the package being released is depended on by other parts of Cotton, update their Cargo.toml dependencies too, like in commit c989d9f1.
3. Check that everything is pushed upstream, both to self-hosted CI and to Github.

   git push main git push github main

4. Check that both CI pipelines are passing; again, there’s a badge for the Github one:

   If your CI includes statistical metrics (as opposed to pass/fail ones: coverage, for example), check that those are in acceptable ranges too.

5. Do a dry-run publish, remembering to cd to the crate directory, not the workspace root:

   cargo publish --dry-run

   Cargo will check that the package is buildable; if any errors occur, fix them and go back to Step 3.
6. Tag the release, using multiple tags if multiple crates are being released:

   git tag cotton-ssdp-0.0.3

7. Push the new tag to both upstreams:

   git push cotton-ssdp-0.0.3 git push github cotton-ssdp-0.0.3

8. Actually publish the crate on crates.io:

   cargo publish

   Hopefully there won’t be any errors, given that the dry-run succeeded.
9. Let any contributors know that their stuff is now in a release – if any pull requests have been merged, now is the time to let those contributors know that they can go back to using real upstream releases of your crate, and potentially stop maintaining their forks.