WebAssembly / WebAssembly/component-model
Interface version / compatibilty changes
Nobody has claimed this yet.
- Dominant language
- WebAssembly
- Stars
- 1.4k
- Forks
- 130
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 15
Description
Wasmtime currently performs a slightly complicated dance to allow a guest import/export of an interface to be linked with a different but semver-compatible host version of that interface. For a description of why this behavior was implemented see https://github.com/bytecodealliance/wasmtime/issues/7860. Based on a discussion with @lukewagner and @alexcrichton we think this behavior can be brought into the spec itself with some relatively straightforward changes:
-
Define "interface version canonicalization", meaning roughly "trimming a version down to the part that matters for compatibility"
- e.g.
0.2.5→0.2,1.2.3→1 - See https://github.com/WebAssembly/component-model/pull/378; specifically https://github.com/WebAssembly/component-model/blob/3c6c4a9f1228676a342d2f971ced73b0e0ba0d2b/design/mvp/BuildTargets.md#interface-name-canonicalization
The definition in this PR preserves semver prerelease tags but we think that may not be necessary.
- e.g.
-
Update
<version>to allow canonical versions in addition to full semver:x(x > 0) and0.y(y > 0) -
To allow round-tripping WIT and nicer error messages, add an optional field to imports/exports that preserves the original full version
- This could contain the entire version (
1.2.3) or just the trimmed suffix (.2.3/2.3)
- This could contain the entire version (
-
(pre-1.0) start enforcing (instead of just allowing) canonical
<version>s
With these spec changes, bindings generators would start emitting canonicalized versions in import/export names. This should effectively give behavior similar to what the Wasmtime linker does today, and additionally should solve the same underlying version compatibility problems for other tools like wac and wasi-virt.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with design/mvp/BuildTargets.md and the linked component-model PR, then review issue #7860 for the existing compatibility behavior. Done means the specification defines interface version canonicalization, accepts canonical versions, preserves original versions for round-tripping, and specifies enforcement before 1.0.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- wasm
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100