Build a new release process for this repository

[alexcrichton]

Currently the release process of this repository is ad-hoc. Someone requests it, I guess what crates need a major/minor bump, I make a PR, and then I publish. No one else can really make a release and I myself make lots of mistakes. The goal of this commit is to design a new process that is less error-prone and can be driven by someone other than me.

Lots of bits and pieces here are lifted from Wasmtime's own release process, but the general idea here is:

• Most crates now all share the same version number of 0.X.0. Exceptions include:

  • wat - uses 1.X.0
  • wast - uses X.0.0
  • wasm-tools - uses 1.X.0

  These exceptions are required for previously published versions.
  Notably wat and wasm-tools are "API stable" so are known to not
  have breaking changes anywhere on the horizon. The wast crate was
  already published at 1.0.0+ so can't use the 0.X.0 numbering of other
  crates.

• The initial version number checked in here, the X in 0.X.0, is 199. This means that the first published version with this new scheme will be 200, explained below.

• To simplify CI and releases merge queues are now enabled for this repository.

• Version bumps are now manually requested in the "Actions" tab of the repository. The "Automated Release Process" workflow is triggered manually with either release-minor or release-major as an argument. When run this will execute a script to update version numbers and a PR is posted.

• Upon merging the automatically produced PR, which has a "magical string" in the commit messages, a release is created when the PR merges to main. This uses artifacts previously built to upload to GitHub Releases. This additionally will publish all crates.

• Bumping version numbers is slightly different than before. For crates using 0.X.Y, they're bumped to 0.(X+1).Y or 0.X.(Y+1) depending on the release. For X.0.Y crates it's either (X+1).0.Y or X.0.(Y+1). For 1.X.Y crates it's either 1.(X+1).Y or 1.X.(Y+1). This enables having a patch release for any historical release.

• Release branches are not made yet. Unlike Wasmtime releases are made by merging a PR to main, not a PR to a release-* branch. Only a tag is created (via CI). Patch releases will require manually creating a branch first. I also haven't tested patch releases due to how rare they are.

• This repository will no longer create a tag-per-crate-and-version pair. Instead only a single tag will be created of the form v1.X.Y depending on the version number of the wasm-tools CLI itself.

The goal of the versioning scheme is to be able to understand where everything is versioned at at-a-glance. There's a clear correlation between wasmparser and wasm-smith now, for example. Additionally I've opted to start everything at 199 since the first released to be published will be one greater which will be 200. I've chosen 200 because wasmparser is already at 121 and I like starting on "nice round numbers".

I've attempted to leave documentation for all the various places, starting in README.md about the high-level steps necessary to make a release. My plan is to make a release immediately after this merges to do a run-through of the whole process to make sure it all works. Assuming everything goes smoothly I'll hope to get someone else to make the next release to ensure that goes smoothly as well. Assuming that goes well we next just hope that folks don't get too angry about the versioning scheme selected.

[alexcrichton]

Also, upon approval, I'll handle merging this. I will update repository settings to require a merge queue and I'll merge this through the merge queue.

[fitzgen]

Nice! Yeah every time I've tried to cut releases in this repo the past couple years things have gotten hairy. Will be nice to have this automated.