Semantic Versioning

[runvnc]

Will web assembly support semantic versioning for modules?

[jfbastien]

Can you elaborate? Version numbers are discussed for dynamic linking, but semantic versioning means many things to many people, so I'm not sure what to answer :-)

[runvnc]

As described here: http://semver.org/

[lukewagner]

A major goal of the wasm binary format is to not require versioning (analogous to how a JS parser isn't versioned: new features translate to new cases in existing switch statements). See this overview for more details. We would, however, likely have a version word very early in the binary stream so that if we ever needed some major overhaul, we would have a place to bump the version, but the goal would be that this version would, like ELF, forever stay at 1.

[jfbastien]

In fact, we want to encourage the usage of feature detection, and allow implementations to ship new features in any order they want. That means there's no linear versioning of wasm past MVP!

[sunfishcode]

I expect the main desire for semver would be for use in dynamic libraries. As far as I know, the question of naming dynamic libraries has not been discussed yet. There are several aspects to naming: versioning, search paths, namespacing, and probably others.

[jfbastien]

@sunfishcode we discussed numbering in the context of #53, especially in concert with SRI.

[runvnc]

I just read this The End of Software Versions
The thing is, when you have a massive monolithic API like ZMQ or (the worst) "HTML5", version numbers cannot be useful.

Semantic versioning does make sense and (usually) works when your modules are all small, specific, and self-contained.

Since there is a single module version packaged in the browser for everything anyone could think of to put in the browser, a "Browser API" version number could not give any information about compatibility of specific sub-APIs and so is less than useful.

In the context of self-contained, decoupled web assembly modules with specific narrowly defined purposes, semantic versioning will be important. If we can't get those types of modules with web assembly in some context then we will be missing something important I believe.

So my suggestion is that at some point pull browser/HTML5 things apart into versioned modules so that we could

import AudioContext from 'audio';

and perhaps specify versions using some @1.x syntax or assembly metadata. Rather than relying on, hoping for certain features to be at certain stages of implementation and finding out at runtime.

[kg]

@runvnc the approach you describe would require WebAssembly to externally enforce versioning on HTML5 APIs that aren't versioned. Furthermore, how does it work if you import v1.x of AudioContext in an environment that has v2.x if they made behavioural changes? They call HTML5 a 'Living Standard' for a reason. :(

[runvnc]

@kg how does feature detection even work with web assembly, since its supposed to be compiled right, and wouldn't that mean that at compile time it would be checking types and function signatures etc. against a specific version or contract of AudioContext?

Maybe they really should be breaking the web platform down into a set of versioned, decoupled modules. Maybe the reason its not like that is because it is all ultimately based on a system (C++) that relies on monolithic applications and predates the existence of contemporary modules and the things that come with them like semantic versioning and registries.

[jfbastien]

It seems like we're definitely doing feature detection.