Preview3 folder?

[vados-cosmonic]

Hey all, this might be quite a huge task but hopefully we can start small and iterate -- it would be great to have a wasip3 folder similar to how we have one for p2. I think at this point the feature set of P3 is very well nailed down, but trying to find coherent documentation on it is somewhat hard (mostly the component-model repo), and it would be nice to have a place to link to, as we have for P2.

AFAIK the current WIT implementations that are most up to date are the ones in https://github.com/bytecodealliance/wasip3-prototyping (though the various wasi-* projects should not be far behind/they should be similar), so now that churn has reduced quite a bit we might be able to represent that stuff here as well.

[ricochet]

The process for releasing wasi 0.2.x includes a final post-process step where we fetch the deps from the proposal repos and then cut a release from this project. We can continue doing this exactly the same as 0.2.x.

One issue that has arisen is that that this muddles the "source of truth". For p3, we could choose to move to a model that is closer to the proposal repos themselves. Before we set up p3 automation (which I'm happy to do and would only take an afternoon), I would like a quick check with key stakeholders that this is what we want.

Do we want to continue copying sources from proposal repos to WASI, or do we want to direct users to the modular interface repos and the releases directly from those projects? I can go either way but now is the best time to make a decision if we want to change.

cc'ing a few folks @yoshuawuyts @sunfishcode @lukewagner @pchickey and will add this as an agenda item for WASI SG.

[pchickey]

Regardless of the source of truth being proposal repos or registries, a fair number of users will land at this repo and expect to see what the ratified wasip3 spec is here alongside wasip2 and the other older specs. If we stopped putting a copy of the spec here, it would probably cause more confusion in new users than it would cost in either mirroring automation or confusion over the source of truth if, somehow, the mirroring automation broke. It makes sense to me that, as part of releasing wasip3 0.3.0, we git mv wasip2 legacy/ and create a new wasip3 directory at the root, and maintain that as point releases of the specs continue on the release train.

[ricochet]

Should the rendered markdown also be included in the copy here?

[pchickey]

We all want to stop rendering the markdown, and p3 is as good a time as any to stop, so lets not!

[ricochet]

In the WASI status meeting last week, the following approach was recommended:

• Turn-key approach for publishing the rc's with minimal manual work
• Use the same versioning strategy from before, v0.3.0-rc-YYYY-MM-DD, e.g. v0.3.0-rc-2025-07-22. The question was asked how to handle multiple revs the same day (where monotonically increasing number would handle it). Since it wasn't a problem last time, we're unlikely to need to handle this edge case. Dates made it easier to align across multiple proposal repos that need to move in lock-step.

Something that did not occur to me in the meeting is that we could hybridize these approaches by defaulting to v0.3.0-rc-YYYY-MM-DD and then when there is a conflict, adding an increment.