Introduction
The Phase 2 entry criteria are defined as follows:
2. Feature Description Available [WASI Subgroup]
Entry requirements:
- The portability criteria are documented in the proposal.
- Precise and complete overview document is available in a proposal repo around which a reasonably high level of consensus exists.
- A wit description of the API exists.
- All dependencies of the wit description must have reached phase 2.
During this phase:
- One or more implementations proceed on prototyping the API.
- A plan is developed for how the portability criteria will be met.
The intended goal of this phase is to garner feedback from users and implementers alike. The reason why we require WIT is to make that feedback practical: it's not just an idea that people get to think about, but a concrete well-defined API. However I've not always found it easy to test out phase 2 proposals, and that's in part because vendoring .wit files from git repos is hard.
Proposal
I would like to propose we require WASI phase 2 proposals to all have packages available and published using the Wasm OCI Artifact Layout, and tagged using semver-compliant labels that match the package version. So if a WIT package is versioned as 0.3.0-preview2, the tag on the registry is tagged with that version too.
Using tools like wkg, wit-deps, and my own upcoming component tool, these packages then becomes easier to depend on and bind against. The OCI protocol is basically just a well-defined way of storing tarballs stored on an S3 bucket and making that reachable HTTP - so even if a project is eager to curl + tar their path to getting package definitions, with this they should be able to.
To be clear: this is not to be prescriptive on how users and projects should obtain package definitions. Using git subdirs or any similar approaches should continue to work. This is just about enabling workflows around OCI-based packaging to be guaranteed to work with all WASI proposals in phase 2 and above.
Updating existing phase 2 proposals
We currently have 6 standalone phase 2 proposals. From what I can tell none of these publish their packages as OCI. Adding new entry requirements to the phase proposal should not only cover new proposals, but also all existing proposals. Which means existing proposals should be required to be upgraded as well.
I'm happy to volunteer to help proposals add publishing automation to their CI pipelines. We’ve added that for the phase 3 proposals already, and adding it to the phase 2 proposals shouldn’t be too hard.
But concretely this should also come with a backstop: if we accept this as a phase 2 entry criterium then we should add a time limit for proposals to migrate or else be downgraded to phase 1. I was thinking 2 standard cycles on the release train (~4 months) should be plenty of time.
Next steps
I’m keen to get feedback on this idea in this thread. But I’m also nominating this for discussion for the next WASI SG meeting. Keen to hear what people think!
Introduction
The Phase 2 entry criteria are defined as follows:
The intended goal of this phase is to garner feedback from users and implementers alike. The reason why we require WIT is to make that feedback practical: it's not just an idea that people get to think about, but a concrete well-defined API. However I've not always found it easy to test out phase 2 proposals, and that's in part because vendoring .wit files from git repos is hard.
Proposal
I would like to propose we require WASI phase 2 proposals to all have packages available and published using the Wasm OCI Artifact Layout, and tagged using semver-compliant labels that match the package version. So if a WIT package is versioned as
0.3.0-preview2, the tag on the registry is tagged with that version too.Using tools like
wkg,wit-deps, and my own upcomingcomponenttool, these packages then becomes easier to depend on and bind against. The OCI protocol is basically just a well-defined way of storing tarballs stored on an S3 bucket and making that reachable HTTP - so even if a project is eager tocurl+tartheir path to getting package definitions, with this they should be able to.To be clear: this is not to be prescriptive on how users and projects should obtain package definitions. Using git subdirs or any similar approaches should continue to work. This is just about enabling workflows around OCI-based packaging to be guaranteed to work with all WASI proposals in phase 2 and above.
Updating existing phase 2 proposals
We currently have 6 standalone phase 2 proposals. From what I can tell none of these publish their packages as OCI. Adding new entry requirements to the phase proposal should not only cover new proposals, but also all existing proposals. Which means existing proposals should be required to be upgraded as well.
I'm happy to volunteer to help proposals add publishing automation to their CI pipelines. We’ve added that for the phase 3 proposals already, and adding it to the phase 2 proposals shouldn’t be too hard.
But concretely this should also come with a backstop: if we accept this as a phase 2 entry criterium then we should add a time limit for proposals to migrate or else be downgraded to phase 1. I was thinking 2 standard cycles on the release train (~4 months) should be plenty of time.
Next steps
I’m keen to get feedback on this idea in this thread. But I’m also nominating this for discussion for the next WASI SG meeting. Keen to hear what people think!