1# Release Process
2
3Wasmtime's release process was [originally designed in an RFC][rfc4] and this
4page is intended to serve as documentation for the current process as-is today.
5The high-level summary of Wasmtime's release process is:
6
7* A new major version of Wasmtime will be made available once a month.
8* Security bugs and correctness fixes will be backported to the latest two
9  releases of Wasmtime and issued as patch releases.
10
11Once a month Wasmtime will issue a new major version. This will be issued with a
12semver-major version update, such as 4.0.0 to 5.0.0. The precise schedule of
13Wasmtime's release is currently an automated PR is sent to bump the version on
14the 5th of every month and a release is made when the PR is merged. The PR
15typically gets merged within a few days.
16
17Each major release of Wasmtime reserves the right to break both behavior and API
18backwards-compatibility. This is not expected to happen frequently, however, and
19any breaking change will follow these criteria:
20
21* Minor breaking changes, either behavior or with APIs, will be documented in
22  the `RELEASES.md` release notes. Minor changes will require some degree of
23  consensus but are not required to go through the entire RFC process.
24
25* Major breaking changes, such as major refactorings to the API, will be
26  required to go through the [RFC process]. These changes are intended to be
27  broadly communicated to those interested and provides an opportunity to give
28  feedback about embeddings. Release notes will clearly indicate if any major
29  breaking changes through accepted RFCs are included in a release.
30
31Patch releases of Wasmtime will only be issued for security and critical
32correctness issues for on-by-default behavior in the previous releases. If
33Wasmtime is currently at version 5.0.0 then 5.0.1 and 4.0.1 will be issued as
34patch releases if a bug is found. Patch releases are guaranteed to maintain API
35and behavior backwards-compatibility and are intended to be trivial for users to
36upgrade to.
37
38Patch releases for Cranelift will be made for any miscompilations found by
39Cranelift, even those that Wasmtime itself may not exercise. Due to the current
40release process a patch release for Cranelift will issue a patch release for
41Wasmtime as well.
42
43## What's released?
44
45At this time the release process of Wasmtime encompasses:
46
47* The `wasmtime` Rust crate
48* The C API of Wasmtime
49* The `wasmtime` CLI tool through the `wasmtime-cli` Rust crate
50
51Other projects maintained by the Bytecode Alliance will also likely be released,
52with the same version numbers, with the main Wasmtime project soon after a
53release is made, such as:
54
55* [`wasmtime-dotnet`](https://github.com/bytecodealliance/wasmtime-dotnet)
56* [`wasmtime-py`](https://github.com/bytecodealliance/wasmtime-py)
57* [`wasmtime-go`](https://github.com/bytecodealliance/wasmtime-go)
58* [`wasmtime-cpp`](https://github.com/bytecodealliance/wasmtime-cpp)
59* [`wasmtime-rb`](https://github.com/bytecodealliance/wasmtime-rb)
60
61Note, though, that bugs and security issues in these projects do not at this
62time warrant patch releases for Wasmtime.
63
64[rfc4]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-one-dot-oh.md
65[RFC process]: https://github.com/bytecodealliance/rfcs
66