Document WebAssembly versions in /features/

[chris-morgan]

If one wants to learn about engine support for specific WebAssembly features, I think https://webassembly.org/features/ is the best information there is; but it’s predicated around individual features, whereas the spec now seems to be versioned, and people will probably normally care more about a major version rather than an individual feature. It would be good to embrace that.

Here’s a sketch of the sort of thing I have in mind:

Two parts to this.

1. A new section for showing the earliest version of each engine supporting each major versions of WebAssembly, which I think is the summary most people want. I also suggest adding release dates for each engine—especially on the web, that’s normally more useful than version number.

2. Add a new header column at the start of the existing features table, grouping phase 5 features by which version of WebAssembly they’re first included in.

Aside: the present sorting of the features is not obvious; most are alphabetical, but they’re being sorted by something that may not even appear in the text, most notably “Non-trapping float-to-int Conversions” is being sorted as “saturatedfloattoint”. I think it would be worth choosing a manual ordering in some cases. The ordering of the groups in the individual features table is also interesting: as phases 5–1 are most mature to least mature, you might want the WASM version sort to ascend, so it’s showing 2.0 then 3.0 then finalised-but-not-yet-included-in-a-release then the degrees of not-finalised.

[dschuff]

I can see how this is a nice organization, but I think there are a couple of problems.
The main underlying thing is that I actually think that developers who want to target wasm (the main audience for this page) actually don't/won't care primarily about major versions. On the web, the browsers mostly implement features in the order that they are standardized, and they start shipping them at phase 4, which is before they get fully merged into the spec and consolidated into a major or minor version. Wasm 3.0 took an exceptionally long time for that to happen and we'll improve that, but even when we do, we don't want engine or toolchain implementors to wait for spec versioning or W3C process machinery to happen before implementing, and we don't want developers to wait before paying attention and generating demand.

Off the web, there is a huge variety of different embeddings and engines, and they are all making decisions about which parts of the spec they care about, for their own reasons. Just because an embedding does not support e.g. GC or relaxed SIMD doesn't mean it's not fully-featured for its purpose, so I'm not sure that tagging implementations as fully complete with respect to the version numbers is very useful.

I'm open to other opinions about this; just in my experience most developers just have a couple of particular features they care about, and there isn't always correlation between those and other features that happen to be in the standards pipeline at the same time.

[rossberg]

@dschuff:

The main underlying thing is that I actually think that developers who want to target wasm (the main audience for this page) actually don't/won't care primarily about major versions.

We introduced versions because there were regular complaints — esp from non-Web folks — that feature lists or "feature timelines" alone are too obscure to anybody not closely following the CG, and that they are not an effective way to communicate baseline support of engines or tools to users or dependencies. And if versions are supposed to be useful, then there is no question that they should appear in the table.

The non-linear implementation chaos you mention has less to do with Wasm versions, but rather with ad-hoc subsetting and the CG's illusion that there is no need for standardising subsets. ;)

That being said, I think the natural order of proposals in the table would be from oldest/most advanced to youngest/least advanced, i.e., 2.0 first, then 3.0, then not-yet-merged phase 5, then phase 4, and so on. (Now that we are "evergreen", the time between reaching phase 5 and a version bump should be fairly short in the future. But it seems totally adequate to have a small section "not yet merged" for proposals in that stage.)

[dschuff]

We introduced versions because there were regular complaints — esp from non-Web folks — that feature lists or "feature timelines" alone are too obscure to anybody not closely following the CG, and that they are not an effective way to communicate baseline support of engines or tools to users or dependencies. And if versions are supposed to be useful, then there is no question that they should appear in the table.

The non-linear implementation chaos you mention has less to do with Wasm versions, but rather with ad-hoc subsetting and the CG's illusion that there is no need for standardising subsets. ;)

Definitely +1 that we should push more on standardizing subsets (despite my belief that there will be ad-hoc subsetting despite that).

That being said, I think the natural order of proposals in the table would be from oldest/most advanced to youngest/least advanced, i.e., 2.0 first, then 3.0, then not-yet-merged phase 5, then phase 4, and so on. (Now that we are "evergreen", the time between reaching phase 5 and a version bump should be fairly short in the future. But it seems totally adequate to have a small section "not yet merged" for proposals in that stage.)

I think my main concern on the web side (or for any implementation or ecosystem that wants to stay up-to-date as much as possible) is that I don't want to show the phase 4 proposals as "not yet released", and developers could use them today (especially where is full browser compatibility).

[rossberg]

Well, according to the process, phase 4 literally is not yet standardised, i.e. released, so we shouldn't pretend otherwise. But we can use a less scary phrasing, like "not yet merged".

[sunfishcode]

Lime1 is a specific subset that has been curated, as an alternative to the relatively uncurated Wasm major versions.