12cff023b6
The `wasmtime` release procees seems like it's been a bit ad-hoc up to this point, so I figured it'd be good to try to document what we do today and codify what should be done as well as a form of release checklist. I've noticed that we have a number of releases (like v0.11.0) but the `Cargo.toml` files in the repository don't reflect the current version of `wasmtime`. Additionally I've noticed that the [most recent release] ended up having failed tests because `Cargo.toml` was modified but `Cargo.lock` wasn't updated. I'm hoping that by having a checklist we can avoid these sorts of accidental issues in the future! [release]: https://github.com/bytecodealliance/wasmtime/runs/434690272
26 lines
1.2 KiB
Markdown
26 lines
1.2 KiB
Markdown
# Release Process
|
|
|
|
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:
|
|
|
|
1. `git pull` - make sure you've got the latest changes
|
|
2. Update the version numbers in `Cargo.toml` for all crates
|
|
* Edit `scripts/bump-wasmtime-version.sh`, notable the `version` variable
|
|
* Run the script
|
|
* Commit the changes
|
|
3. Send this version update as a PR to the wasmtime repository, wait for a merge
|
|
4. After merging, tag the merge as `vA.B.C`
|
|
5. Push the tag to the repository
|
|
* This will trigger the release CI which will create all release artifacts and
|
|
publish them to GitHub releases.
|
|
6. Run `scripts/publish-all.sh` to publish all crates to crates.io
|
|
|
|
And that's it, then you've done a wasmtime release.
|