WASI's three previews, two interface definition languages, and a repository holding no headers

This repository holds discussion and goals, while each API lives somewhere else

The first thing to understand is that you are looking at a coordination space, not an implementation. Development of each API happens in its own repository, and the entry point to all of them is a proposals list kept at docs/Proposals.md. What this repository is for is stated plainly: general discussion, a record of how the group works, and high-level goals. The root listing matches that description, with docs/, proposals/, specifications/ and assets/ directories alongside CONTRIBUTING.md, LICENSE.md and a README that fits on one screen. So if you arrived expecting interface definitions, headers or a build to run, the wrong repository is the reason. The definitions you actually compile against live in whichever API repository the proposals list points to.

Preview 1 was described in witx, and Preview 2 replaced it with Wit

Two interface definition languages appear in the history, and the switch between them is the single most consequential fact on the page. WASI started by launching what is now called Preview 1, an API defined using the witx IDL, and that generation is described as widely used. WASI 0.2, also called Preview 2, is a modular collection of APIs defined with the Wit IDL instead. The two older generations are reached through their own branches in the repository, wasi-0.1 and wasi-0.2, which is a reminder that even the historical shapes are kept separately rather than collapsed into one.

Preview 2 names four lessons learned, and virtualizability is the odd one out

The stated lessons carried into 0.2 are four, and they are worth separating because one of them is about the shape of the specification while the rest are about reach. First, support for a wider range of source languages, which is what turns a system interface from a C era contract into something a language with a real compiler can target. Second, modularity, and here the word shows up twice in the project: the API is a modular collection, and each API lives in its own repository. Third, a more expressive type system. Fourth, virtualizability, which is the only item that is about running the interface rather than writing it, and the only one with no elaboration anywhere on the page.

Preview 3 drops explicit streams and polling for future and stream types

The current preview is described as building on 0.2 rather than replacing it, and the change it makes is specific. It replaces the earlier explicit streams and polling interfaces with the component model's own composable async functionality, delivered through the future and stream types. The mechanism moves rather than disappears: instead of a polling loop the host drives, asynchrony is expressed in the type system as values you hold and pass around. That is why the component model is named here at all, since those two types come from it rather than from WASI.

Preview 1 and 0.2 get their own branches, Preview 3 gets an anchor in a markdown file

The three link definitions at the bottom of the page read like a filing system, and they differ in a way that tells you something about maturity. Preview 1 points at a wasi-0.1 tree, and WASI 0.2 points at a wasi-0.2 tree, so both older generations have dedicated branches holding their definitions. WASI 0.3 does not have a branch link at all; it points to docs/Proposals.md at the inclusion in WASI 0.3 anchor. So the two settled generations are versioned in git and the current one is tracked as a proposal entry. Nothing on the page dates any of this, and no version number is given for the preview you would target today beyond the words current preview.

New proposals must adopt the template repository and the Wit documentation

There is an onboarding path, and it is prescriptive. To create a proposal you are told to start with the Contributing guide. Then the requirement: all new API proposals should use the new format and the new repository structure shown in the proposal template, which lives in the separate wasi-proposal-template repository. The word should carries the intent, since nothing on the page says what happens to a proposal written in the old format or who decides that a difference is acceptable. For the language side there is a dedicated document, docs/WitInWasi.md, covering how to use Wit in a WASI proposal. Between the guide, the template and that document, a new contributor is told where to go without being told how long review takes.

Tags v0.2.12, v0.3.0 and v0.3.1 date the previews, not a stable interface

The recent tags read like a document series rather than a library with a compatibility promise. v0.3.0 was published 2026-06-11, v0.3.1 on 2026-08-11 and v0.3.2 on 2026-10-13. What that sequence shows is a minor bump followed by point releases about two months apart, while the last push to main was 2026-11-01, after all three tags. Nothing in the naming scheme promises that a 0.2 consumer keeps working when 0.3 lands, which is consistent with an interface still under standardization. One more detail is worth reading directly: the license field carries no recognized identifier at all, and a LICENSE.md file is present in the root instead.

Editorial conclusion

Follow it if you are building WebAssembly host interfaces and need to know which generation to target, then go read the individual API repositories, since this one carries discussion and goals rather than code. Pin to a preview and expect the interface language to move, given that witx gave way to Wit between Preview 1 and 0.2. Before depending on anything here, read the license file yourself, because the license field in the metadata holds no recognized identifier even though a LICENSE.md file sits in the root.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. WebAssembly/WASI on GitHub