1# Tiers of Support in Wasmtime 2 3Wasmtime's support for platforms and features can be distinguished with three 4different tiers of support. The description of these tiers are intended to be 5inspired by the [Rust compiler's support tiers for 6targets](https://doc.rust-lang.org/rustc/target-tier-policy.html) but are 7additionally tailored for Wasmtime. Wasmtime's tiered support additionally 8applies not only to platforms/targets themselves but additionally features 9implemented within Wasmtime itself. 10 11The purpose of this document is to provide a means by which to evaluate the 12inclusion of new features and support for existing features within Wasmtime. 13This should not be used to "lawyer" a change into Wasmtime on a precise 14technical detail or similar since this document is itself not 100% precise and 15will change over time. 16 17## Current Tier Status 18 19For explanations of what each tier means see below. 20 21#### Tier 1 22 23| Category | Description | 24|----------------------|--------------------------------------------| 25| Target | `x86_64-apple-darwin` | 26| Target | `x86_64-pc-windows-msvc` | 27| Target | `x86_64-unknown-linux-gnu` | 28| Compiler | Cranelift [^support] | 29| Compiler | Winch [^support] | 30| WebAssembly Proposal | [`mutable-globals`] | 31| WebAssembly Proposal | [`sign-extension-ops`] | 32| WebAssembly Proposal | [`nontrapping-float-to-int-conversion`] | 33| WebAssembly Proposal | [`multi-value`] | 34| WebAssembly Proposal | [`bulk-memory`] | 35| WebAssembly Proposal | [`reference-types`] | 36| WebAssembly Proposal | [`simd`] | 37| WebAssembly Proposal | [`component-model`] | 38| WebAssembly Proposal | [`relaxed-simd`] | 39| WebAssembly Proposal | [`multi-memory`] | 40| WebAssembly Proposal | [`tail-call`] | 41| WebAssembly Proposal | [`extended-const`] | 42| WebAssembly Proposal | [`memory64`] | 43| WASI Proposal | [`wasi-io`] | 44| WASI Proposal | [`wasi-clocks`] | 45| WASI Proposal | [`wasi-filesystem`] | 46| WASI Proposal | [`wasi-random`] | 47| WASI Proposal | [`wasi-sockets`] | 48| WASI Proposal | [`wasi-http`] | 49| WASI Proposal | `wasi_snapshot_preview1` | 50| WASI Proposal | `wasi_unstable` | 51| Embedding API | Rust | 52| Embedding API | C | 53 54[`mutable-globals`]: https://github.com/WebAssembly/mutable-global/blob/master/proposals/mutable-global/Overview.md 55[`sign-extension-ops`]: https://github.com/WebAssembly/spec/blob/master/proposals/sign-extension-ops/Overview.md 56[`nontrapping-float-to-int-conversion`]: https://github.com/WebAssembly/spec/blob/master/proposals/nontrapping-float-to-int-conversion/Overview.md 57[`multi-value`]: https://github.com/WebAssembly/spec/blob/master/proposals/multi-value/Overview.md 58[`bulk-memory`]: https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md 59[`extended-const`]: https://github.com/WebAssembly/extended-const 60[`reference-types`]: https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md 61[`simd`]: https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md 62[`wasi-clocks`]: https://github.com/WebAssembly/wasi-clocks 63[`wasi-filesystem`]: https://github.com/WebAssembly/wasi-filesystem 64[`wasi-io`]: https://github.com/WebAssembly/wasi-io 65[`wasi-random`]: https://github.com/WebAssembly/wasi-random 66[`wasi-sockets`]: https://github.com/WebAssembly/wasi-sockets 67[`wasi-http`]: https://github.com/WebAssembly/wasi-http 68[`tail-call`]: https://github.com/WebAssembly/tail-call/blob/main/proposals/tail-call/Overview.md 69 70[^support]: Compiler support is further broken down [below](#compiler-support) 71 into finer-grained target/wasm proposal combinations. Compilers are not 72 required to support the full matrix of all tier 1 targets/proposals. 73 74#### Tier 2 75 76| Category | Description | Missing Tier 1 Requirements | 77|----------------------|----------------------------|-----------------------------| 78| Target | `aarch64-unknown-linux-gnu`| Continuous fuzzing | 79| Target | `aarch64-apple-darwin` | Continuous fuzzing | 80| Target | `s390x-unknown-linux-gnu` | Continuous fuzzing | 81| Target | `x86_64-pc-windows-gnu` | Clear owner of the target | 82| Target | Support for `#![no_std]` | Support beyond CI checks | 83| WebAssembly Proposal | [`custom-page-sizes`] | Unstable wasm proposal | 84| WebAssembly Proposal | [`exception-handling`] | fuzzing, dependence on GC | 85| WebAssembly Proposal | [`function-references`] | production quality | 86| WebAssembly Proposal | [`gc`] | production quality | 87| WebAssembly Proposal | [`threads`] | fuzzing, API quality | 88| WebAssembly Proposal | [`wide-arithmetic`] | Unstable wasm proposal | 89| Execution Backend | Pulley | More time fuzzing/baking | 90| Embedding API | C++ | Full-time maintainer | 91 92[`memory64`]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md 93[`custom-page-sizes`]: https://github.com/WebAssembly/custom-page-sizes 94[`multi-memory`]: https://github.com/WebAssembly/multi-memory/blob/master/proposals/multi-memory/Overview.md 95[`threads`]: https://github.com/WebAssembly/threads 96[`component-model`]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md 97[`relaxed-simd`]: https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md 98[`function-references`]: https://github.com/WebAssembly/function-references/blob/main/proposals/function-references/Overview.md 99[`wide-arithmetic`]: https://github.com/WebAssembly/wide-arithmetic/blob/main/proposals/wide-arithmetic/Overview.md 100[`exception-handling`]: https://github.com/WebAssembly/exception-handling 101[`stack-switching`]: https://github.com/WebAssembly/stack-switching 102 103#### Tier 3 104 105| Category | Description | Missing Tier 2 Requirements | 106|----------------------|-----------------------------------|-----------------------------| 107| Target | `aarch64-apple-ios` | CI testing, full-time maintainer | 108| Target | `aarch64-linux-android` | CI testing, full-time maintainer | 109| Target | `aarch64-pc-windows-msvc` | CI testing, full-time maintainer | 110| Target | `aarch64-unknown-linux-musl` [^4] | CI testing, full-time maintainer | 111| Target | `armv7-unknown-linux-gnueabihf` | full-time maintainer | 112| Target | `i686-pc-windows-msvc` | CI testing, full-time maintainer | 113| Target | `i686-unknown-linux-gnu` | full-time maintainer | 114| Target | `powerpc64le-unknown-linux-gnu` | CI testing, full-time maintainer | 115| Target | `riscv32imac-unknown-none-elf`[^5]| CI testing, full-time maintainer | 116| Target | `riscv64gc-unknown-linux-gnu` | full-time maintainer | 117| Target | `wasm32-wasip1` [^3] | Supported but not tested | 118| Target | `x86_64-linux-android` | CI testing, full-time maintainer | 119| Target | `x86_64-unknown-freebsd` | CI testing, full-time maintainer | 120| Target | `x86_64-unknown-illumos` | CI testing, full-time maintainer | 121| Target | `x86_64-unknown-linux-musl` [^4] | CI testing, full-time maintainer | 122| Target | `x86_64-unknown-none` [^5] | CI testing, full-time maintainer | 123| WASI Proposal | [`wasi-nn`] | More expansive CI testing | 124| WASI Proposal | [`wasi-threads`] | More CI, unstable proposal | 125| WASI Proposal | [`wasi-config`] | unstable proposal | 126| WASI Proposal | [`wasi-keyvalue`] | unstable proposal | 127| WASI Proposal | [`wasi-tls`] | unstable proposal | 128| *misc* | Non-Wasmtime Cranelift usage [^1] | CI testing, full-time maintainer | 129| *misc* | DWARF debugging [^2] | CI testing, full-time maintainer, improved quality | 130 131[`wasi-nn`]: https://github.com/WebAssembly/wasi-nn 132[`wasi-threads`]: https://github.com/WebAssembly/wasi-threads 133[`wasi-config`]: https://github.com/WebAssembly/wasi-config 134[`wasi-keyvalue`]: https://github.com/WebAssembly/wasi-keyvalue 135[`wasi-tls`]: https://github.com/WebAssembly/wasi-tls 136[`gc`]: https://github.com/WebAssembly/gc 137 138[^1]: This is intended to encompass features that Cranelift supports as a 139general-purpose code generator such as integer value types other than `i32` and 140`i64`, non-Wasmtime calling conventions, code model settings, relocation 141restrictions, etc. These features aren't covered by Wasmtime's usage of 142Cranelift because the WebAssembly instruction set doesn't leverage them. This 143means that they receive far less testing and fuzzing than the parts of Cranelift 144exercised by Wasmtime. 145 146[^2]: Currently there is no active maintainer of DWARF debugging support and 147support is currently best-effort. Additionally there are known shortcomings 148and bugs. At this time there's no developer time to improve the situation here 149as well. 150 151[^3]: Wasmtime's `cranelift` and `winch` features can be compiled to WebAssembly 152but not the `runtime` feature at this time. This means that 153Wasmtime-compiled-to-wasm can itself compile wasm but cannot execute wasm. 154 155[^4]: Binary artifacts for MUSL are dynamically linked, not statically 156linked, meaning that they are not suitable for "run on any linux distribution" 157style use cases. Wasmtime does not have static binary artifacts at this time and 158that will require building from source. 159 160[^5]: Rust targets that are `#![no_std]` don't support the entire feature set of 161Wasmtime. For example the `threads` Cargo feature requires the standard library. 162For more information see the [`no_std` documentation][nostd]. Additionally these 163targets are sound in the presence of multiple threads but will panic on 164contention of data structures. If you're doing multithreaded things in `no_std` 165please file an issue so we can help solve your use case. 166 167[nostd]: ./stability-platform-support.md 168 169#### Unsupported features and platforms 170 171While this is not an exhaustive list, Wasmtime does not currently have support 172for the following features. Note that this is intended to document Wasmtime's 173current state and does not mean Wasmtime does not want to ever support these 174features; rather design discussion and PRs are welcome for many of the below 175features to figure out how best to implement them and at least move them to Tier 1763 above. 177 178* Target: [AArch64 FreeBSD](https://github.com/bytecodealliance/wasmtime/issues/5499) 179* Target: [NetBSD/OpenBSD](https://github.com/bytecodealliance/wasmtime/issues/6962) 180* Cranelift Target: [i686 (32-bit Intel targets)](https://github.com/bytecodealliance/wasmtime/issues/1980) 181* Cranelift Target: ARM 32-bit 182* Cranelift Target: MIPS 183* Cranelift Target: SPARC 184* Cranelift Target: PowerPC 185* Cranelift Target: RISC-V 32-bit 186* WebAssembly Proposals: see [documentation here](./stability-wasm-proposals.md) 187* [WASI proposal: `proxy-wasm`](https://github.com/proxy-wasm/spec) 188* [WASI proposal: `wasi-blob-store`](https://github.com/WebAssembly/wasi-blob-store) 189* [WASI proposal: `wasi-crypto`](https://github.com/WebAssembly/wasi-crypto) 190* [WASI proposal: `wasi-data`](https://github.com/WebAssembly/wasi-data) 191* [WASI proposal: `wasi-distributed-lock-service`](https://github.com/WebAssembly/wasi-distributed-lock-service) 192* [WASI proposal: `wasi-grpc`](https://github.com/WebAssembly/wasi-grpc) 193* [WASI proposal: `wasi-message-queue`](https://github.com/WebAssembly/wasi-message-queue) 194* [WASI proposal: `wasi-parallel`](https://github.com/WebAssembly/wasi-parallel) 195* [WASI proposal: `wasi-pubsub`](https://github.com/WebAssembly/wasi-pubsub) 196* [WASI proposal: `wasi-sql`](https://github.com/WebAssembly/wasi-sql) 197* [WASI proposal: `wasi-url`](https://github.com/WebAssembly/wasi-url) 198 199#### Compiler Support 200 201Compiler backends of Wasmtime, at this time Cranelift and Winch, are further 202refined in the below table in their support for various architectures and 203WebAssembly features. Tier 1 WebAssembly feature are required to be supported by 204at least one compiler on all Tier 1 targets, and similarly for Tier 2 features 205and so on. Note that architecture here is independent of OS, meaning that 206support is uniform across Wasmtime's supported target for each tier. The legend 207here is: 208 209* ✅ - fully supported 210* �� - work-in-progress 211* ❌ - not supported yet 212 213##### x86\_64 214 215| Feature | Cranelift | Winch | 216|-----------------------------------------|-----------|--------| 217| [`mutable-globals`] | ✅ | ✅ | 218| [`sign-extension-ops`] | ✅ | ✅ | 219| [`nontrapping-float-to-int-conversion`] | ✅ | ✅ | 220| [`multi-value`] | ✅ | ✅ | 221| [`bulk-memory`] | ✅ | ✅ | 222| [`reference-types`] | ✅ | ❌[^a] | 223| [`simd`] | ✅ | ✅ | 224| [`component-model`] | ✅ | ✅ | 225| [`relaxed-simd`] | ✅ | ❌ | 226| [`multi-memory`] | ✅ | ✅ | 227| [`threads`] | ✅ | ✅ | 228| [`tail-call`] | ✅ | ❌ | 229| [`extended-const`] | ✅ | ✅ | 230| [`memory64`] | ✅ | ✅ | 231| [`function-references`] | ✅ | ❌ | 232| [`gc`] | ✅ | ❌ | 233| [`wide-arithmetic`] | ✅ | ✅ | 234| [`custom-page-sizes`] | ✅ | ✅ | 235| [`exception-handling`] | ✅ | ❌ | 236| [`stack-switching`] | �� | ❌ | 237 238##### aarch64 239 240| Feature | Cranelift | Winch[^c] | 241|-----------------------------------------|-----------|-----------| 242| [`mutable-globals`] | ✅ | ✅ | 243| [`sign-extension-ops`] | ✅ | ✅ | 244| [`nontrapping-float-to-int-conversion`] | ✅ | ✅ | 245| [`multi-value`] | ✅ | ✅ | 246| [`bulk-memory`] | ✅ | ✅ | 247| [`reference-types`] | ✅ | ❌[^a] | 248| [`simd`] | ✅ | ❌ | 249| [`component-model`] | ✅ | ✅ | 250| [`relaxed-simd`] | ✅ | ❌ | 251| [`multi-memory`] | ✅ | ✅ | 252| [`threads`] | ✅ | ❌ | 253| [`tail-call`] | ✅ | ❌ | 254| [`extended-const`] | ✅ | ✅ | 255| [`memory64`] | ✅ | ✅ | 256| [`function-references`] | ✅ | ❌ | 257| [`gc`] | ✅ | ❌ | 258| [`wide-arithmetic`] | ✅ | ❌ | 259| [`custom-page-sizes`] | ✅ | ✅ | 260| [`exception-handling`] | ✅ | ❌ | 261| [`stack-switching`] | ❌ | ❌ | 262 263##### s390x 264 265| Feature | Cranelift | Winch | 266|-----------------------------------------|-----------|--------| 267| [`mutable-globals`] | ✅ | ❌ | 268| [`sign-extension-ops`] | ✅ | ❌ | 269| [`nontrapping-float-to-int-conversion`] | ✅ | ❌ | 270| [`multi-value`] | ✅ | ❌ | 271| [`bulk-memory`] | ✅ | ❌ | 272| [`reference-types`] | ✅ | ❌[^a] | 273| [`simd`] | ✅ | ❌ | 274| [`component-model`] | ✅ | ❌ | 275| [`relaxed-simd`] | ✅ | ❌ | 276| [`multi-memory`] | ✅ | ❌ | 277| [`threads`] | ✅ | ❌ | 278| [`tail-call`] | ✅ | ❌ | 279| [`extended-const`] | ✅ | ❌ | 280| [`memory64`] | ✅ | ❌ | 281| [`function-references`] | ✅ | ❌ | 282| [`gc`] | ✅ | ❌ | 283| [`wide-arithmetic`] | ✅ | ❌ | 284| [`custom-page-sizes`] | ✅ | ❌ | 285| [`exception-handling`] | ✅ | ❌ | 286| [`stack-switching`] | ❌ | ❌ | 287 288##### riscv64 289 290| Feature | Cranelift | Winch | 291|-----------------------------------------|-----------|--------| 292| [`mutable-globals`] | ✅ | ❌ | 293| [`sign-extension-ops`] | ✅ | ❌ | 294| [`nontrapping-float-to-int-conversion`] | ✅ | ❌ | 295| [`multi-value`] | ✅ | ❌ | 296| [`bulk-memory`] | ✅ | ❌ | 297| [`reference-types`] | ✅ | ❌[^a] | 298| [`simd`] | ✅ | ❌ | 299| [`component-model`] | ✅ | ❌ | 300| [`relaxed-simd`] | ✅ | ❌ | 301| [`multi-memory`] | ✅ | ❌ | 302| [`threads`] | ✅ | ❌ | 303| [`tail-call`] | ✅ | ❌ | 304| [`extended-const`] | ✅ | ❌ | 305| [`memory64`] | ✅ | ❌ | 306| [`function-references`] | ✅ | ❌ | 307| [`gc`] | ✅ | ❌ | 308| [`wide-arithmetic`] | ✅ | ❌ | 309| [`custom-page-sizes`] | ✅ | ❌ | 310| [`exception-handling`] | ✅ | ❌ | 311| [`stack-switching`] | ❌ | ❌ | 312 313##### Pulley 314 315Note that the pulley "architecture" is a stand-in for Wasmtime's baseline 316support for all platforms. This is how Wasmtime's interpreter works and this is 317intended to work on all platforms. The columns here are for compiler support for 318emitting Pulley bytecode. 319 320| Feature | Cranelift | Winch | 321|-----------------------------------------|-----------|--------| 322| [`mutable-globals`] | ✅ | ❌ | 323| [`sign-extension-ops`] | ✅ | ❌ | 324| [`nontrapping-float-to-int-conversion`] | ✅ | ❌ | 325| [`multi-value`] | ✅ | ❌ | 326| [`bulk-memory`] | ✅ | ❌ | 327| [`reference-types`] | ✅ | ❌[^a] | 328| [`simd`] | ✅ | ❌ | 329| [`component-model`] | ✅ | ❌ | 330| [`relaxed-simd`] | ✅ | ❌ | 331| [`multi-memory`] | ✅ | ❌ | 332| [`threads`] | ❌[^b] | ❌ | 333| [`tail-call`] | ✅ | ❌ | 334| [`extended-const`] | ✅ | ❌ | 335| [`memory64`] | ✅ | ❌ | 336| [`function-references`] | ✅ | ❌ | 337| [`gc`] | ✅ | ❌ | 338| [`wide-arithmetic`] | ✅ | ❌ | 339| [`custom-page-sizes`] | ✅ | ❌ | 340| [`exception-handling`] | ✅ | ❌ | 341| [`stack-switching`] | ❌ | ❌ | 342 343[^a]: Winch supports some features of the [`reference-types`] proposal such as 344 the change to support multiple tables and LEB-encoding table indices in 345 instructions, but it does not support GC types such as `externref` or the 346 new table opcodes in the [`reference-types`] proposal. 347[^b]: Pulley does not support the [`threads`] proposal because there is no known 348 safe way to implement this with Rust's memory model. 349[^c]: Winch's support for aarch64 is complete for Core Wasm. 350 351## Tier Details 352 353Wasmtime's precise definitions of tiers are not guaranteed to be constant over 354time, so these descriptions are likely to change over time. Tier 1 is classified 355as the highest level of support, confidence, and correctness for a component. 356Each tier additionally encompasses all the guarantees of previous tiers. 357 358Features classified under a particular tier may already meet the criteria for 359later tiers as well. In situations like this it's not intended to use these 360guidelines to justify removal of a feature at any one point in time. Guidance is 361provided here for phasing out unmaintained features but it should be clear under 362what circumstances work "can be avoided" for each tier. 363 364#### Tier 3 - Not Production Ready 365 366The general idea behind Tier 3 is that this is the baseline for inclusion of 367code into the Wasmtime project. This is not intended to be a catch-all "if a 368patch is sent it will be merged" tier. Instead the goal of this tier is to 369outline what is expected of contributors adding new features to Wasmtime which 370might be experimental at the time of addition. This is intentionally not a 371relaxed tier of restrictions but already implies a significant commitment of 372effort to a feature being included within Wasmtime. 373 374Tier 3 features include: 375 376* Inclusion of a feature does not impose unnecessary maintenance overhead on 377 other components/features. Some examples of additions to Wasmtime which would 378 not be accepted are: 379 380 * An experimental feature doubles the time of CI for all PRs. 381 * A change which makes it significantly more difficult to architecturally 382 change Wasmtime's internal implementation. 383 * A change which makes building Wasmtime more difficult for unrelated 384 developers. 385 386 In general Tier 3 features are off-by-default at compile time but still 387 tested-by-default on CI. 388 389* New features of Wasmtime cannot have major known bugs at the time of 390 inclusion. Landing a feature in Wasmtime requires the feature to be correct 391 and bug-free as best can be evaluated at the time of inclusion. Inevitably 392 bugs will be found and that's ok, but anything identified during review must 393 be addressed. 394 395* Code included into the Wasmtime project must be of an acceptable level of 396 quality relative to the rest of the code in Wasmtime. 397 398* There must be a path to a feature being finished at the time of inclusion. 399 Adding a new backend to Cranelift for example is a significant undertaking 400 which may not be able to be done in a single PR. Partial implementations of a 401 feature are acceptable so long as there's a clear path forward and schedule 402 for completing the feature. 403 404* New components in Wasmtime must have a clearly identified owner who is willing 405 to be "on the hook" for review, updates to the internals of Wasmtime, etc. For 406 example a new backend in Cranelift would need to have a maintainer who is 407 willing to respond to changes in Cranelift's interfaces and the needs of 408 Wasmtime. 409 410This baseline level of support notably does not require any degree of testing, 411fuzzing, or verification. As a result components classified as Tier 3 are 412generally not production-ready as they have not been battle-tested much. 413 414Features classified as Tier 3 may be disabled in CI or removed from the 415repository as well. If a Tier 3 feature is preventing development of other 416features then the owner will be notified. If no response is heard from within a 417week then the feature will be disabled in CI. If no further response happens 418for a month then the feature may be removed from the repository. 419 420#### Tier 2 - Almost Production Ready 421 422This tier is meant to encompass features and components of Wasmtime which are 423well-maintained, tested well, but don't necessarily meet the stringent criteria 424for Tier 1. Features in this category may already be "production ready" and safe 425to use. 426 427Tier 2 features, organized by category, include: 428 429* **Target** 430 * Tests are run in CI for this platform with a compiler, either 431 directly or via emulation. This ensures that all changes to Wasmtime are 432 tested against this target, and this additionally means that all applicable 433 Tier 1/2 features are tested on this target in CI. 434 435 * Complete implementations for anything that's part of Tier 1. For 436 example all Tier 2 targets must implement all of the applicable Tier 1 437 WebAssembly proposals, and all Tier 2 features must be implemented on all 438 Tier 1 targets. 439 440* **WebAssembly Proposal** 441 * Must be fully tested on CI. This means that it must pass tests on all 442 applicable Tier 1 and Tier 2 target/compiler combos. Note that only one 443 compiler is required to implement the feature at this time, but it must run, 444 via some compiler, on all targets. 445 * The upstream WebAssembly proposal is stage 3+. 446 447* **WASI Proposal** 448 * Similar to WebAssembly proposals this must be fully tested on CI. WASI 449 proposals at Tier 2 must support all Tier 1/2 targets, however. 450 451* **Maintenance** 452 * All existing developers are expected to handle minor changes which affect 453 Tier 2 components. For example if Cranelift's interfaces change then the 454 developer changing the interface is expected to handle the changes for Tier 455 2 architectures so long as the affected part is relatively minor. Note that 456 if a more substantial change is required to a Tier 2 component then that 457 falls under the next bullet. 458 459 * Maintainers of a Tier 2 feature are responsive (reply to requests within a 460 week) and are available to accommodate architectural changes that affect 461 their component. For example more expansive work beyond the previous bullet 462 where contributors can't easily handle changes are expected to be guided or 463 otherwise implemented by Tier 2 maintainers. 464 465 * Major changes otherwise requiring an RFC that affect Tier 2 components are 466 required to consult Tier 2 maintainers in the course of the RFC. Major 467 changes to Tier 2 components themselves do not require an RFC, however. 468 469Features at this tier generally are not turned off or disabled for very long. 470Maintainers are already required to be responsive to changes and will be 471notified of any unrelated change which affects their component. It's recommended 472that if a component breaks for one reason or another due to an unrelated change 473that the maintainer either contributes to the PR-in-progress or otherwise has a 474schedule for the implementation of the feature. 475 476#### Tier 1 - Production Ready 477 478This tier is intended to be the highest level of support in Wasmtime for any 479particular feature, indicating that it is suitable for production environments. 480This conveys a high level of confidence in the Wasmtime project about the 481specified features. 482 483Tier 1 features, broken down by category, include: 484 485* **WebAssembly Proposal** 486 * Continuous fuzzing is required for at least one target. This means that any 487 WebAssembly proposal must have support in the `wasm-smith` crate and 488 existing fuzz targets must be running and exercising the new code paths. 489 Where possible differential fuzzing should also be implemented to compare 490 results with other implementations. 491 492 * Must meet [all stabilization requirements](./stability-wasm-proposals.md). 493 494* **Target** 495 * A target's architecture must be continuously fuzzing via at least one 496 Rust target. For example currently there are three x86\_64 targets that are 497 considered Tier 1 but only `x86_64-unknown-linux-gnu` is fuzzed. 498 499* **Compiler** 500 * A compiler, like a target, must be continuously fuzzed on at least one 501 target to be considered Tier 1 for a particular target. 502 503* **Maintenance** 504 * CVEs and security releases will be performed as necessary for any bugs found 505 in features and targets. 506 507 * Major changes affecting this component may require help from maintainers 508 with specialized expertise, but otherwise it should be reasonable to expect 509 most Wasmtime developers to be able to maintain Tier 1 features. 510 511 * Major changes affecting Tier 1 features require an RFC and prior agreement 512 on the change before an implementation is committed. 513 514A major inclusion point for this tier is intended to be the continuous fuzzing 515of Wasmtime. This implies a significant commitment of resources for fixing 516issues, hardware to execute Wasmtime, etc. Additionally this tier comes with the 517broadest expectation of "burden on everyone else" in terms of what changes 518everyone is generally expected to handle. 519 520Features classified as Tier 1 are rarely, if ever, turned off or removed from 521Wasmtime. 522