WASI follows the WebAssembly CG Phases process, with the following adaptations:
-
Entry into Stage 2 requires witx specifications.
-
Starting in Stage 2, proposals may follow WASI's [ephemeral/snapshot/old] process to provide a balance between the need for stability so that toolchains and engines can sync up, and the need for evolution.
-
The Phase 4's entry requirements for "Two or more Web VMs implement the feature", "At least one toolchain implements the feature", and "The formalization and the reference interpreter are usually updated (though these two can be done as part of step 3 at the Working Group chair's discretion)." are waived.
In their place, as an additional entry requirement into Phase 2, champion(s) must include a set of entry criteria into Phase 4 in their proposal, which the Subgroup will vote on as part of Phase 2 approval.
Phase 4 criteria will vary depending on the API and its expected use cases, but may include things like multiple independent production implementations, implementations on multiple host platforms, polyfill implementations, and bindings in toolchains and libraries. Note that, portability requirements may vary between proposals, as not all features will necessarily make sense in all host environments.
-
The specific process in Phases 4 and 5 will be determined when we have a proposal ready for them.
-
Requirements around the reference interpreter don't apply.
-
WASI proposals don't require formal notation. Formal notation may be used in the documentation of a feature, but it isn't expected to be practical for all APIs.