In need of a ChangeLog

[juj]

Today I was googling for information on WebAssembly memory.size instruction, and trying to answer whether I can safely use it and expect it to work on all Wasm implementations. Was it part of MVP? When was it introduced? Do I need to feature test for support for that? If so, which "feature package" is it part of?

While looking for answers, I stumbled to find that https://webassembly.github.io/spec/core/index.html now reads "Release 1.1". I have definitely missed the 1.1 release. My understanding from before was that we had Wasm "MVP", and then on top of that a large collection of individual features that are displayed in https://webassembly.org/roadmap/ that one needs to feature test for.

All of this gets more confusing the more I read:

• which browsers support Wasm 1.1?
• which browser versions did different browsers adopt Wasm 1.1?
• when was it introduced?
• what is different between Wasm 1.0 (== was that what we called the Wasm "MVP"?) and Wasm 1.1?
• looking at https://webassembly.org/roadmap/, it highlights that browsers are shipping Wasm 1.0. Then maybe it means that Wasm 1.1 is still in draft stage, and no browser is shipping it? Or is that page out of date and 1.1 is ubiquitous?
• How do the different features in https://webassembly.org/roadmap/ relate to Wasm 1.1? Are some of the features "subsumed" into Wasm 1.1? Or will they be separate?

Would it be too much to ask if each browser vendor could drop in comments to one of the issues, e.g. at WebAssembly/website#187 or Fyrd/caniuse#5687 to when they ship a Wasm feature in a browser?

Would it be possible to maintain a ChangeLog to list the changes between versions?

It feels like any time I need to figure out browser marketshare for Wasm features to answer whether we can use feature X of WebAssembly (or whether X even is a feature, or if it is something that has been part of it from the MVP) when shipping Unity or Tiny, it ends up in a hours long googling spree to WebKit/Chromium/Bugzilla bug trackers to try to figure out which browser vendor published what when, and in the end using mozregression and/or manual bisecting to try out different browser versions. I wish there was a better way. 😭

[rossberg]

Don't read too much into the version number. W3C requires it for its specs. The Wasm MVP was numbered 1.0. There hasn't been another official W3C release version yet.

Informally, for Wasm, we adopted a "living standard" model, where the doc always reflects what has been approved by the WG, and implementations are expected to keep up with that. That's the MVP + all finished proposals.

The doc was bumped to 1.1 Draft when we merged the first post-MVP proposals -- because it no longer reflects the 1.0 spec. But it's not 1.1 yet either, from the W3C perspective it's merely an intermediate draft. The title page says Draft explicitly, so there shouldn't be any confusion.

That said, there is support for the idea of having a page tracking implementation status of various engines. There already is an issue for that, see WebAssembly/proposals#21. I suppose somebody just has to volunteer to do the work.

[Schweinepriester]

@rossberg does that still hold true with 2.0?

Landed here via https://www.heise.de/news/WebAssembly-2-0-First-Public-Drafts-zur-neuen-Version-liegen-jetzt-vor-6745010.html and thinking about if I should open an issue for browser support on caniuse and finding Fyrd/caniuse#5687 then.

[tlively]

Yes, the version number is still a formality. The important thing is still which proposals have reached phase 5 and have been merged into the spec repo.

[juj]

Now with the version number being bumped to 2.0 there is even a greater need to find a succinct documentation about "what does WebAssembly 2.0 contain that WebAssembly MVP did not?", and "which browsers support full WebAssembly 2.0 from which version onwards"?

This issue, and the related issues WebAssembly/website#187 and Fyrd/caniuse#5687 still direly need attention.

Yes, the version number is still a formality.

I am not sure I understand the meaning of this. If the meaning is that users should practically "ignore" the number, it does not help that W3C is making it a newspiece that the version number is now 2.0:

https://www.w3.org/blog/news/archives/9509
https://www.phoronix.com/scan.php?page=news_item&px=WASM-2.0-Public-Drafts
https://www.infoworld.com/article/3657593/webassembly-20-begins-to-take-shape.html

These kinds of news items will make people talk about "WebAssembly 2.0" as a Thing, and we have already got our first inquiries at Unity about "hey when are you planning to support WebAssembly 2.0?".

Looks like https://webassembly.github.io/spec/core/appendix/changes.html is focused on 1.0 vs 2.0 differences, and based on that page, it seems that the intent of 2.0 is to just bucket together a number of individual subfeatures to a common feature level. Is that right? Is the set of subfeatures frozen/set in stone yet, or is it planned to potentially evolve before 2.0 is ratified?

Will the version identifier in the .wasm binary files change?

[tlively]

These kinds of news items will make people talk about "WebAssembly 2.0" as a Thing, and we have already got our first inquiries at Unity about "hey when are you planning to support WebAssembly 2.0?".

Yikes! If you look at the WG notes from when this was decided, you will see that it is definitely not a Thing: https://github.com/WebAssembly/meetings/blob/main/main/2022/WG-04-13.md.

Looks like https://webassembly.github.io/spec/core/appendix/changes.html is focused on 1.0 vs 2.0 differences, and based on that page, it seems that the intent of 2.0 is to just bucket together a number of individual subfeatures to a common feature level. Is that right? Is the set of subfeatures frozen/set in stone yet, or is it planned to potentially evolve before 2.0 is ratified?

Basically the way we cut spec releases is changing so the WG decided to bump the version number just to mark the beginning of the new process. That's the intent of 2.0 and has absolutely nothing to do with the contents of the spec.

The effect of the version bump is that yes, all the proposals merged so far are just bucketed under a new version number. I believe the idea is that every new proposal merged in the future will result in a new spec being published, but I'm not sure whether the version number will continue changing or if it will be WebAssembly 2.0 forever. It's a little unclear from the WG notes.

Will the version identifier in the .wasm binary files change?

No, and I would be surprised if it ever does given our back-compat requirements.

[rossberg]

@Schweinepriester, yes and no. There is some process and bureaucracy involved. :)

In the future, we want to make version numbers more significant again, since they're more succinct and ease communication. The idea that we arrived at was to bump the minor version with each new proposal (or set of proposals) that is merged from now on.

At the same time we want to switch to W3C's "evergreen" model (as has been decided before), since that significantly lowers the burden of making releases. But technically, that does not allow us to change the W3C "version" anymore afterwards.

To reconcile this seemingly incompatible requirements, we figured that we can bump the W3C "version" to plain 2 once (rebranding 1.1, including all changes since 1.0), and as far as W3C process is involved, we will stay at that indefinitely. Additionally, we use minor numbers to mark "releases" that cycle through updates within that model. As far as W3C process is concerned, this minor number has no meaning (their version remains plain 2), but the spec uses it "internally".

The binary format version is unrelated to any of this.

We intend to discuss this in more detail at one of the next CG meetings. But the WG had to move because we needed to renew the charter. And switching to evergreen required bumping the version one way or the other. And as a consequence, W3C made an official announcement.

In summary, technically speaking, WebAssembly 2.0 actually is a Thing. But it's just 1.1 draft renamed, which already was the "live" standard informally. From there on, we hope to have useful minor release numbers when a relevant addition makes it to the spec. :)