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