Automate more of Wasmtime's release process (#3422)

* Automate more of Wasmtime's release process

This change revamps the release process for Wasmtime and intends to make
it nearly 100% automated for major release and hopefully still pretty
simple for patch releases. New workflows are introduced as part of
this commit:

* Once a month a PR is created with major version bumps
* Specifically hinted commit messages to the `main` branch will get
  tagged and pushed to the main repository.
* On tags we'll now not only build releases after running CI but
  additionally crates will be published to crates.io.

In conjunction with other changes this means that the release process
for a new major version of Wasmtime is simply merging a PR. Patch
releases will involve running some steps locally but most of the
nitty-gritty should be simply merging the PR that's generated.

* Use an anchor in a regex

docs/contributing-release-process.md

@@ -4,34 +4,65 @@ This is intended to serve as documentation for Wasmtime's release process. It's
 largely an internal checklist for those of us performing a Wasmtime release, but
 others might be curious in this as well!
 
-To kick off the release process someone decides to do a release. Currently
-there's not a schedule for releases or something similar. Once the decision is
-made (there's also not really a body governing these decisions, it's more
-whimsical currently, or on request from others) then the following steps need to
-be executed to make the release:
+## Releasing a major version
 
-1. Double-check that there are no open [rustsec advisory
-   issues][rustsec-issues] on the Wasmtime repository.
-1. `git pull` - make sure you've got the latest changes
-1. Run `rustc scripts/publish.rs`
-1. Run `./publish bump`
-  * Review and commit the changes
-  * Note that this bumps all cranelift/wasmtime versions as a major version bump
-    at this time. See the `bump_version` function in `publish.rs` to tweak this.
-1. Make sure `RELEASES.md` is up-to-date, and fill it out if it doesn't have an
-   entry yet for the current release.
-1. Send this version update as a PR to the `wasmtime` repository, wait for a merge
-1. After merging, tag the merge as `vA.B.C`
-1. Push the tag to the repository
-  * This will trigger the release CI which will create all release artifacts and
-    publish them to GitHub releases.
-1. Run `./publish publish`
-  * This will fail on some crates, but that's expected.
-  * Keep running this script until all crates are published. Note that crates.io
-    won't let you publish something twice so rerunning is only for crates which
-    need the index to be udpated and if it hasn't yet. It's recommended to wait
-    a bit between runs of the script.
+Major versions of Wasmtime are relased once-a-month. Most of this is automatic
+and **all that needs to be done is to merge the GitHub PR that CI will
+generate** on the second Monday of each month.
 
-And that's it, then you've done a Wasmtime release.
+Specifically what happens for a major version release is:
+
+1. One day a month (configured via `.github/workflows/bump-version.yml`) a CI job
+   will run. This CI job will:
+  * Download the current `main` branch
+  * Run `./scripts/publish.rs` with the `bump` argument
+  * Commit the changes with a special marker in the commit message
+  * Push these changes to a branch
+  * Open a PR with this branch against `main`
+1. A maintainer of Wasmtime signs off on the PR and merges it.
+  * Most likely someone will need to push updates to `RELEASES.md` beforehand.
+  * A maintainer should double-check there are [no open security issues][rustsec-issues].
+1. The `.github/workflow/push-tag.yml` workflow is triggered on all commits to
+   `main`, including the one just created with a PR merge. This workflow will:
+   * Scan the git logs of pushed changes for the special marker added by
+     `bump-version.yml`.
+   * If found, tags the current `main` commit and pushes that to the main
+     repository.
+1. Once a tag is created CI runs in full on the tag itself. CI for tags will
+   create a GitHub release with release artifacts and it will also publish
+   crates to crates.io. This is orchestrated by `.github/workflows/main.yml`.
+
+If all goes well you won't have to read up much on this and after hitting the
+Big Green Button for the automatically created PR everything will merrily carry
+on its way.
 
 [rustsec-issues]: https://github.com/bytecodealliance/wasmtime/issues?q=RUSTSEC+is%3Aissue+is%3Aopen+
+
+## Releasing a patch release
+
+Making a patch release is somewhat more manual than a major version. At this
+time the process for making a patch release of `2.0.1` the process is:
+
+1. All patch release development should be happening on a branch
+   `release-2.0.1`.
+  * Maintainers need to double-check that the `PUBLIC_CRATES` listed in
+    `scripts/publish.rs` do not have semver-API-breaking changes (in the
+    strictest sense). All security fixes must be done in such a way that the API
+    doesn't break between the patch version and the original version.
+1. Locally check out `release-2.0.1` and make sure you're up-to-date.
+1. Run `rustc scripts/publish.rs`
+1. Run `./publish bump-patch`
+1. Update `RELEASES.md`
+1. Commit the changes. Include the marker
+   `[automatically-tag-and-release-this-commit]` in your commit message.
+1. Make a PR against the `release-2.0.1` branch.
+1. Merge the PR when CI is green
+  * Note that if historical branches may need updates to source code or CI to
+    pass itself since the CI likely hasn't been run in a month or so. When in
+    doubt don't be afraid to pin the Rust version in use to the rustc version
+    that was stable at the time of the branch's release.
+
+From this point automated processes should take care of the rest of the steps,
+basically resuming from step 3 above for major releases where `push-tag.yml`
+will recognize the commit message and push an appropriate tag. This new tag will
+then trigger full CI and building of release artifacts.