1# Release Process
2
3This is intended to serve as documentation for Wasmtime's release process. It's
4largely an internal checklist for those of us performing a Wasmtime release, but
5others might be curious in this as well!
6
7## Releasing a major version
8
9Major versions of Wasmtime are relased once-a-month. Most of this is automatic
10and **all that needs to be done is to merge the GitHub PR that CI will
11generate** on the second Monday of each month.
12
13Specifically what happens for a major version release is:
14
151. One day a month (configured via `.github/workflows/bump-version.yml`) a CI job
16   will run. This CI job will:
17  * Download the current `main` branch
18  * Run `./scripts/publish.rs` with the `bump` argument
19  * Commit the changes with a special marker in the commit message
20  * Push these changes to a branch
21  * Open a PR with this branch against `main`
221. A maintainer of Wasmtime signs off on the PR and merges it.
23  * Most likely someone will need to push updates to `RELEASES.md` beforehand.
24  * A maintainer should double-check there are [no open security issues][rustsec-issues].
251. The `.github/workflow/push-tag.yml` workflow is triggered on all commits to
26   `main`, including the one just created with a PR merge. This workflow will:
27   * Scan the git logs of pushed changes for the special marker added by
28     `bump-version.yml`.
29   * If found, tags the current `main` commit and pushes that to the main
30     repository.
311. Once a tag is created CI runs in full on the tag itself. CI for tags will
32   create a GitHub release with release artifacts and it will also publish
33   crates to crates.io. This is orchestrated by `.github/workflows/main.yml`.
34
35If all goes well you won't have to read up much on this and after hitting the
36Big Green Button for the automatically created PR everything will merrily carry
37on its way.
38
39[rustsec-issues]: https://github.com/bytecodealliance/wasmtime/issues?q=RUSTSEC+is%3Aissue+is%3Aopen+
40
41## Releasing a patch release
42
43Making a patch release is somewhat more manual than a major version. At this
44time the process for making a patch release of `2.0.1` the process is:
45
461. All patch release development should be happening on a branch
47   `release-2.0.1`.
48  * Maintainers need to double-check that the `PUBLIC_CRATES` listed in
49    `scripts/publish.rs` do not have semver-API-breaking changes (in the
50    strictest sense). All security fixes must be done in such a way that the API
51    doesn't break between the patch version and the original version.
521. Locally check out `release-2.0.1` and make sure you're up-to-date.
531. Run `rustc scripts/publish.rs`
541. Run `./publish bump-patch`
551. Update `RELEASES.md`
561. Commit the changes. Include the marker
57   `[automatically-tag-and-release-this-commit]` in your commit message.
581. Make a PR against the `release-2.0.1` branch.
591. Merge the PR when CI is green
60  * Note that if historical branches may need updates to source code or CI to
61    pass itself since the CI likely hasn't been run in a month or so. When in
62    doubt don't be afraid to pin the Rust version in use to the rustc version
63    that was stable at the time of the branch's release.
64
65From this point automated processes should take care of the rest of the steps,
66basically resuming from step 3 above for major releases where `push-tag.yml`
67will recognize the commit message and push an appropriate tag. This new tag will
68then trigger full CI and building of release artifacts.
69