Skip to content

Latest commit

 

History

History
111 lines (87 loc) · 8.82 KB

Proposals.md

File metadata and controls

111 lines (87 loc) · 8.82 KB

WASI proposals

WASI APIs are developed as proposals. These proposals go through 5 phases of development (following the WebAssembly CG's Phase Process).

You can learn more about contributing new proposals (and other ways to contribute) in our Contributing guide.

Active Proposals

Phase 5 - The Feature is Standardized (WG)

Proposal Champion Versions

Phase 4 - Standardize the Feature (WG)

Proposal Champion Versions

Phase 3 - Implementation Phase (CG + WG)

Proposal Champion Versions
I/O Dan Gohman
Clocks Dan Gohman
Random Dan Gohman
Filesystem Dan Gohman
Sockets Dave Bakker
CLI Dan Gohman
HTTP Piotr Sikora, Jiaxiao Zhou, Dan Chiarlone, David Justice, Luke Wagner

Phase 2 - Proposed Spec Text Available (CG + WG)

Proposal Champion Versions
Machine Learning (wasi-nn) Andrew Brown and Mingqiu Sun

Phase 1 - Feature Proposal (CG)

Proposal Champion Versions
Blob Store Jiaxiao Zhou, Dan Chiarlone, David Justice
Crypto Frank Denis and Daiki Ueno
Digital I/O Emiel Van Severen
Distributed Lock Service Jiaxiao Zhou, Dan Chiarlone, David Justice
I2C Friedrich Vandenberghe
Key-value Store Jiaxiao Zhou, Dan Chiarlone, David Justice
Logging Dan Gohman
Message Queue Jiaxiao Zhou, Dan Chiarlone, David Justice
Parallel Andrew Brown
Pattern Match Jianjun Zhu
Pub/sub Jiaxiao Zhou, Dan Chiarlone, David Justice
Runtime Config Jiaxiao Zhou, Dan Chiarlone, David Justice
SPI Emiel Van Severen
SQL Jiaxiao Zhou, Dan Chiarlone, David Justice
SQL Embed Kyle Brown
Threads Alexandru Ene, Marcin Kolny, Andrew Brown
URL Radu Matei

Phase 0 - Pre-Proposal (CG)

Note: The pre-proposal phase is simply meant as a way to share ideas. This means that there may be overlap between pre-proposals. It also means that the WASI subgroup has not yet decided that the pre-proposal is in scope for WASI.

Proposal Champion Versions
proxy-wasm/spec (will advance as multiple, smaller proposals) Piotr Sikora

Versioning

Once a proposal reaches Phase 3, we expect the champions to start creating releases, following the conventions of semantic versioning (semver). Releases for active proposals are linked in the chart above.

Proposals remain in the 0.x semver range until they reach Phase 5 and are fully standardized. At that point, a 1.0 release should be made available.

For some APIs, it makes sense to add new features after the API itself has reached Phase 5. These feature additions should go through the same standardization process. Once they have reached Phase 5, the minor version number of the release should be incremented.

Some APIs may require backwards-incompatible changes over time. In these cases, we allow proposals to increment the major version number only if the old API can be implmented in terms of the new API. As part of the new version, champions are expected to provide a tool that enables this backwards-compatibility. If that is not possible, then a new API proposal with a new name should be started. The original API can then be deprecated over time if it makes sense to do so.