T0b1/wasmtime
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
0ca3249afad08266a887faf5ddd7fdf82cbb7920
wasmtime/docs/stability-release.md
Alex Crichton 5f53fd5ca2 Clarify patch release criteria (#3940) 
In today's Wasmtime meeting we discussed the acceptance criteria for
patch releases for Wasmtime and Cranelift. The criteria we came up with
were:

* Cranelift will get a patch release for any miscompilation, whether or
  not it affects Wasmtime.
* Wasmtime will get a patch release for security issues and bugs which
  seriously hinder usability.

The consensus at the time was that due to Wasmtime's monthly release
schedule we want to be pretty strict about what generates a patch
release, hence the threshold being at serious bugs as opposed to any
bugs found.

This commit attempts to update the `stability-release.md` document with
our documented release process. The release cadence section is brought
up to date, the Wasmtime section was edited slightly (it largely already
said this which I only just realized), and a Cranelift section was
added.
2022-03-18 09:09:50 -05:00

3.1 KiB
Raw Blame History

Release Process

Wasmtime's release process was originally designed in an RFC and this page is intended to serve as documentation for the current process as-is today. The high-level summary of Wasmtime's release process is:

  • A new major version of Wasmtime will be made available once a month.
  • Security bugs and correctness fixes will be backported to the latest two releases of Wasmtime and issued as patch releases.

Once a month Wasmtime will issue a new major version. This will be issued with a semver-major version update, such as 4.0.0 to 5.0.0. The precise schedule of Wasmtime's release is currently an automated PR is sent to bump the version on the 5th of every month and a release is made when the PR is merged. The PR typically gets merged within a few days.

Each major release of Wasmtime reserves the right to break both behavior and API backwards-compatibility. This is not expected to happen frequently, however, and any breaking change will follow these criteria:

  • Minor breaking changes, either behavior or with APIs, will be documented in the RELEASES.md release notes. Minor changes will require some degree of consensus but are not required to go through the entire RFC process.

  • Major breaking changes, such as major refactorings to the API, will be required to go through the RFC process. These changes are intended to be broadly communicated to those interested and provides an opportunity to give feedback about embeddings. Release notes will clearly indicate if any major breaking changes through accepted RFCs are included in a release.

Patch releases of Wasmtime will only be issued for security and critical correctness issues for on-by-default behavior in the previous releases. If Wasmtime is currently at version 5.0.0 then 5.0.1 and 4.0.1 will be issued as patch releases if a bug is found. Patch releases are guaranteed to maintain API and behavior backwards-compatibility and are intended to be trivial for users to upgrade to.

Patch releases for Cranelift will be made for any miscompilations found by Cranelift, even those that Wasmtime itself may not exercise. Due to the current release process a patch release for Cranelift will issue a patch release for Wasmtime as well.

What's released?

At this time the release process of Wasmtime encompasses:

  • The wasmtime Rust crate
  • The C API of Wasmtime
  • The wasmtime CLI tool through the wasmtime-cli Rust crate

Other projects maintained by the Bytecode Alliance will also likely be released, with the same version numbers, with the main Wasmtime project soon after a release is made, such as:

Note, though, that bugs and security issues in these projects do not at this time warrant patch releases for Wasmtime.