1# Release Process 2 3Wasmtime's release process was [originally designed in an RFC][rfc4] and later 4amended with [an LTS process][rfc-lts] and this page is intended to serve as 5documentation for the current process as-is today. 6 7The high-level summary of Wasmtime's release process is: 8 9* A new major version of Wasmtime will be made available on the 20th of each 10 month. 11* Each release that is a multiple of 12 is considered an LTS release and is 12 supported for 24 months. Other releases are supported for 2 months. 13* Security bugs are guaranteed to be backported to all supported releases. 14* Bug fixes are backported on a volunteer basis. 15 16[rfc-lts]: https://github.com/bytecodealliance/rfcs/pull/42 17 18## Current Versions 19 20<div id='version-table'> 21 22This is a table of supported, recent, and some upcoming releases of Wasmtime 23along with the dates around their release process. Rows in **bold** are 24actively supported at this time. 25 26| Version | LTS | Branch Date | Release Date | EOL Date | 27|------------|-----|-------------|--------------|----------| 28 29<noscript> 30JavaScript is disabled so the table above is empty. 31</noscript> 32 33In more visual form this is a gantt chart of the current release trains: 34 35<noscript> 36JavaScript is disabled there is no gantt chart to show. 37</noscript> 38 39</div> 40 41 42## New Versions 43 44Once a month Wasmtime will issue a new major version. This will be issued with a 45semver-major version update, such as 4.0.0 to 5.0.0. Releases are created from 46main with a new `release-X.0.0` git branch on the 5th of every month. The 47release itself then happens on the 20th of the month, or shortly after if that 48happens to fall on a weekend. 49 50Each major release of Wasmtime reserves the right to break both behavior and API 51backwards-compatibility. This is not expected to happen frequently, however, and 52any breaking change will follow these criteria: 53 54* Minor breaking changes, either behavior or with APIs, will be documented in 55 the `RELEASES.md` release notes. Minor changes will require some degree of 56 consensus but are not required to go through the entire RFC process. 57 58* Major breaking changes, such as major refactorings to the API, will be 59 required to go through the [RFC process]. These changes are intended to be 60 broadly communicated to those interested and provides an opportunity to give 61 feedback about embeddings. Release notes will clearly indicate if any major 62 breaking changes through accepted RFCs are included in a release. 63 64All releases will have an accompanying `RELEASES.md` on the release branch 65documenting major and minor changes made during development. Note that each 66branch only contains the release notes for that branch, but links are provided 67for older release notes. 68 69For maintainers, performing a release is [documented 70here](./contributing-release-process.md#releasing-a-major-version). 71 72## Version Support 73 74Wasmtime major version releases are of one of two categories: 75 76* LTS release - this happens every 12 releases of Wasmtime and the version 77 number is always divisible by 12. LTS releases are supported for 24 months. 78 For example Wasmtime 24.0.0 is supported for 2 years. 79 80* Normal release - this is every release other than an LTS release. Normal 81 releases are supported for 2 months. For example Wasmtime 31.0.0 is supported 82 for 2 months. 83 84At any one time Wasmtime has two supported LTS releases and up to two supported 85normal releases. Once a version of Wasmtime is release the project strives to 86maintain binary/version compatibility with dependencies and such throughout the 87lifetime of the release. For example the minimum supported version of Rust 88required to compile a version of Wasmtime will not increase. Exceptions may be 89made to LTS branches though if the versions of tooling to produce the LTS itself 90have fallen out-of-date. For example if an LTS was originally produced with a 91GitHub Actions runner that is no longer available then the oldest supported 92image will be used instead. 93 94## Patch Versions 95 96Patch releases of Wasmtime will only be issued for security and critical 97correctness issues for on-by-default behavior in supported releases. For example 98if the current version is 39.0.0 then a security issue would issue a new release 99for: 100 101* 39.0.x - the current release 102* 38.0.x - the last release 103* 36.0.x - the current LTS release 104* 24.0.x - the last LTS release 105 106Patch releases are guaranteed to maintain API and behavior 107backwards-compatibility and are intended to be trivial for users to upgrade to. 108 109The Wasmtime project guarantees backports and patch releases will be made for 110any discovered security issue. Other bug fixes are done on a best-effort basis 111in accordance with volunteers able to do the backports (see below). The Wasmtime 112project does not support backporting new features to older releases, even if a 113volunteer performs a backport for the project. 114 115Patch releases for Cranelift will be made for any miscompilations found by 116Cranelift, even those that Wasmtime itself may not exercise. Due to the current 117release process a patch release for Cranelift will issue a patch release for 118Wasmtime as well. 119 120Patch releases do not have a set cadence and are done on an as-needed basis. For 121maintainers, performing a patch release is [documented 122here](./contributing-release-process.md#releasing-a-patch-version). 123 124## Security Fixes 125 126Security fixes will be issued as patch releases of Wasmtime. They follow the 127same process as normal backports except that they're coordinated in private 128prior to patch release day. 129 130For maintainers, performing a security release is [documented 131here](./security-vulnerability-runbook.md). 132 133## What's released? 134 135At this time the release process of Wasmtime encompasses: 136 137* The `wasmtime` Rust crate 138* The C API of Wasmtime 139* The `wasmtime` CLI tool through the `wasmtime-cli` Rust crate 140 141Other projects maintained by the Bytecode Alliance will also likely be released, 142with the same version numbers, with the main Wasmtime project soon after a 143release is made, such as: 144 145* [`wasmtime-dotnet`](https://github.com/bytecodealliance/wasmtime-dotnet) 146* [`wasmtime-py`](https://github.com/bytecodealliance/wasmtime-py) 147* [`wasmtime-go`](https://github.com/bytecodealliance/wasmtime-go) 148* [`wasmtime-cpp`](https://github.com/bytecodealliance/wasmtime-cpp) 149* [`wasmtime-rb`](https://github.com/bytecodealliance/wasmtime-rb) 150 151Note, though, that bugs and security issues in these projects do not at this 152time warrant patch releases for Wasmtime. 153 154[rfc4]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-one-dot-oh.md 155[RFC process]: https://github.com/bytecodealliance/rfcs 156 157## Releases and "CI Weather" 158 159Wasmtime relies on GitHub Actions to perform a release. This is true for both 160normal releases and security releases. GitHub Actions has become much less 161reliable over time and is often subject to widespread outages which can prevent 162Wasmtime from making a release. At this time Wasmtime has no alternative for 163making a release and we're entirely subject to the whims of Azure and GitHub 164Actions and how they're doing that day. If there is an outage when a release is 165being made then Wasmtime will not be able to make a release. This can affect the 166timely publish of a security release, for example. We do our best to keep tabs 167on the status of GitHub Actions and will publish a release once it recovers if 168there's an outage. 169 170Wasmtime as a project does not currently have the resources to dedicate to 171self-hosted runners, different CI providers, or maintaining escape hatches to 172perform releases locally instead of CI. If you maintain an embedding of 173Wasmtime and this caveat is unacceptable to you please feel free to reach out. 174We would be happy to talk about coordinating alternative CI architecture coupled 175with external investment in maintainership. For now, though, GitHub Actions is 176the best option available to us even with its unreliability. 177