Skip to content

Commit ef3c605

Browse files
sunfishcodesunfishcode
authored
Start moving WASI to a CG-style phases process. (#252)
Adapt the WebAssembly CG's phases process for WASI, and make an initial mapping of current WASI proposals to phases within this process. This is quite rough at this time, and not everything fits in quite yet, and we can adjust things. This is a first step, and we'll work for greater harmonization as we proceed.
1 parent 490a406 commit ef3c605

File tree

3 files changed

+109
-24
lines changed

3 files changed

+109
-24
lines changed

‎docs/Process.md

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
# WASI Standardization Process
2+
3+
WASI follows the [WebAssembly CG Phases process], with the following adaptations:
4+
5+
- Entry into Stage 2 requires [witx] specifications.
6+
7+
- Starting in Stage 2, proposals may follow WASI's [ephemeral/snapshot/old] process
8+
to provide a balance between the need for stability so that toolchains and engines
9+
can sync up, and the need for evolution.
10+
11+
- The Phase 4's entry requirements for "Two or more Web VMs implement the feature",
12+
"At least one toolchain implements the feature", and "The formalization and the
13+
reference interpreter are usually updated (though these two can be done as part
14+
of step 3 at the Working Group chair's discretion)." are waived.
15+
16+
In their place, as an additional entry requirement into Phase 2, champion(s) must
17+
include a set of entry criteria into Phase 4 in their proposal, which the Subgroup
18+
will vote on as part of Phase 2 approval.
19+
20+
Phase 4 criteria will vary depending on the API and its expected use cases,
21+
but may include things like multiple independent production implementations,
22+
implementations on multiple host platforms, polyfill implementations, and
23+
bindings in toolchains and libraries. Note that, portability requirements may
24+
vary between proposals, as not all features will necessarily make sense in all
25+
host environments.
26+
27+
- The specific process in Phases 4 and 5 will be determined when we have a
28+
proposal ready for them.
29+
30+
- Requirements around the reference interpreter don't apply.
31+
32+
- WASI proposals don't require formal notation. Formal notation may be used in the
33+
documentation of a feature, but it isn't expected to be practical for all APIs.
34+
35+
[WebAssembly CG Phases process]: https://github.com/WebAssembly/meetings/blob/master/process/phases.md
36+
[witx]: https://github.com/WebAssembly/WASI/blob/master/docs/witx.md
37+
[ephemeral/snapshot/old process]: https://github.com/WebAssembly/WASI/blob/master/phases/README.md

‎docs/Proposals.md

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
# WASI proposals
2+
3+
This page is under construction. The intent is to follow the CG's
4+
[proposals page], but adapted for [WASI]. Some of the proposals predate our
5+
adoption of this process and so don't fit exactly into the defined phases,
6+
however our intention is to align them going forward.
7+
8+
[WASI]: https://github.com/WebAssembly/WASI
9+
[proposals page]: https://github.com/WebAssembly/proposals/blob/master/README.md
10+
11+
## Active proposals
12+
13+
Proposals follow [this process document](https://github.com/WebAssembly/WASI/blob/master/docs/Process.md).
14+
15+
### Phase 4 - Standardize the Feature (WG)
16+
17+
| Proposal | Champion |
18+
| ------------------------------------------------------------------------------ | -------------------------------------- |
19+
20+
### Phase 3 - Implementation Phase (CG + WG)
21+
22+
| Proposal | Champion |
23+
| ------------------------------------------------------------------------------ | -------------------------------------- |
24+
25+
### Phase 2 - Proposed Spec Text Available (CG + WG)
26+
27+
| Proposal | Champion |
28+
| ------------------------------------------------------------------------------ | -------------------------------------- |
29+
| [I/O][wasi-io] | Dan Gohman |
30+
| [Filesystem][wasi-filesystem] | Dan Gohman |
31+
| [Command-Line][wasi-command-line] | Dan Gohman |
32+
| [Clocks][wasi-clocks] | Dan Gohman |
33+
| [Random][wasi-random] | Dan Gohman |
34+
| [Misc][wasi-misc] | Dan Gohman |
35+
36+
### Phase 1 - Feature Proposal (CG)
37+
38+
| Proposal | Champion |
39+
| ------------------------------------------------------------------------------ | -------------------------------------- |
40+
| [Crypto][wasi-crypto] | Frank Denis and Daiki Ueno |
41+
42+
### Phase 0 - Pre-Proposal (CG)
43+
44+
| Proposal | Champion |
45+
| ------------------------------------------------------------------------------ | -------------------------------------- |
46+
| [proxy-wasm][wasi-proxy-wasm] | Piotr Sikora |
47+
48+
### Contributing new proposals
49+
50+
Please see [Contributing to WebAssembly](https://github.com/WebAssembly/WASI/blob/master/Contributing.md) for the most up-to-date information on contributing proposals to standard.
51+
52+
[wasi-io]: https://github.com/WebAssembly/WASI/phases
53+
[filesystem]: https://github.com/WebAssembly/WASI/phases
54+
[wasi-command-line]: https://github.com/WebAssembly/WASI/phases
55+
[clocks]: https://github.com/WebAssembly/WASI/phases
56+
[random]: https://github.com/WebAssembly/WASI/phases
57+
[misc]: https://github.com/WebAssembly/WASI/phases
58+
[wasi-crypto]: https://github.com/WebAssembly/WASI-crypto
59+
[wasi-proxy-wasm]: https://github.com/WebAssembly/WASI

‎phases/README.md

Lines changed: 13 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,17 @@
1-
# WASI development process
1+
# WASI's ephemeral/snapshot/old Process
22

3-
## WASI uses a 3-phase process:
3+
For the standardization process, WASI overall uses a [process]
4+
modeled after the WebAssembly CG's phased process.
5+
6+
For development of features in Phase 2 and later of that process, WASI
7+
has a ephemeral/snapshot/old process, which is designed to allow
8+
for a balance between the need for stability to allow people to build
9+
compatible implementations, libraries, and tools and gain implementation
10+
experience, and the need for proposals to evolve.
11+
12+
[phases process]: https://github.com/WebAssembly/WASI/blob/master/phases/README.md
13+
14+
## The ephemeral/snapshot/old Phases
415

516
- [`ephemeral`](ephemeral): The development staging area. New API
617
proposals API-changing fixes to existing APIs should be submitted
@@ -37,25 +48,3 @@
3748
versions, the old API modules are moved to the `old` directory. When
3849
possible, `old` APIs may be accompanied by polyfill modules which
3950
implement their API in terms of newer versions of the API.
40-
41-
## Rationale
42-
43-
### Relationship to the CG's phases
44-
45-
When WASI becomes more mature, such that we have an established base
46-
and we're adding incremental functionality to it, we may want to adopt
47-
a process like [the CG's phases]. However, right now, everything in
48-
WASI is undergoing changes, so we have a greater need to iterate with
49-
flexibility.
50-
51-
### Relationship to standards
52-
53-
WASI should eventually become a standard at the level of WebAssembly
54-
itself. Right now, it needs a lot of work before it's ready. The
55-
`snapshot` tree is meant to serve a practical purpose for people who
56-
want to work with APIs today, with the understanding that everything
57-
is still evolving. It's not meant as a replacement for proper
58-
standardization, which will happen once the overall API is more
59-
mature.
60-
61-
[the CG's phases]: https://github.com/WebAssembly/meetings/blob/master/process/phases.md

0 commit comments

Comments
 (0)