-
Notifications
You must be signed in to change notification settings - Fork 694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 1? #1513
Comments
This is working as intended. The version number in the binary format is there in case we ever need to introduce a new version of the binary format that would require implementations to use a completely different parser implementation. Adding new features is kind of a breaking change because old parsers cannot parse modules that use newer features, but the feature version in the binary format is not meant to address that kind of change. In other words, the binary format version is not the same as the WebAssembly spec version. From the spec itself:
|
Shouldn’t that be backwards-compatible not forwards? I would assume forwards compatibility is when you can run new code on an old system. Which may be the source of confusion leading to this issue. |
Yeah, we've discussed adding mechanism to allow real forward compatibility like that (e.g. conditional sections and feature detection) but they never got very far. |
I guess I meant it's a bit weird that the spec says "The binary format is intended to be forward-compatible, such that future extensions can be made without incrementing its version." which is not true from the wikipedia definition of forwards compatibility. "Forward compatibility or upward compatibility is a design characteristic that allows a system to accept input intended for a later version of itself." e.g. I can't use a WASM binary compiled with GC with an old browser without GC. Maybe it shouldn't talk about forward compatibility at all until such a mechanism is in the standard? |
I agree. Rewording that spec note would be reasonable. |
Closing via WebAssembly/spec#1855 |
Many tools are now creating wasm files with magic number 1 in the first bytes, even though they are not compatible with wasm version 1, as they contain extra features. How did this malpractice become so widespread and what are measures to eliminate this urgent problem?
The text was updated successfully, but these errors were encountered: