Make component::Linker semver-aware
#7994
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit is an implementation of bytecodealliance#7860 for Wasmtime where `wasmtime::component::Linker` is now "semver aware". This means that it assumes that hosts are always managing WIT interfaces in a semver-aare fashion meaning that semver-compatible upgrade exclusively adds functionality. This neatly fits into the idea of subtyping at the instance-level where if a binary built against 0.2.0 only requests a subset of functionality from a runtime that provides 0.2.1, that should work just fine. Specifically what this change does is: * For all names inserted into a `Linker` there might also be a "semver compatible name" which is registered as well. For example `[email protected]` is also registered as `..@1`. * Semver-compatible names are only provided for versions without a prerelease and with either a nonzero major or minor version number. * When looking up an item in the linker if no exact match is found then if a semver-compatible-name is available for the lookup key then that's consulted as well. This semantically means that if a components imports WASI 0.2.0 then a runtime which only provides WASI 0.2.1 will be able to instantiate the component. Furthermore if a component imports WASI 0.2.1 but only imports the subset of WASI that was available in 0.2.0 then it will be instantiable in a runtime that only supports 0.2.0. This implementation is intended to be a crucial part of the evolution to WASI to make it more seamless to upgrade WASI from both a host and guest perspective. This no longer requires everyone to upgrade to the same version all at the same time but instead decouples the upgrade schedules. Closes bytecodealliance#7860
github-actions
bot
added
the
wasmtime:api
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
pchickey
approved these changes
Feb 27, 2024
Contributor
pchickey
left a comment
pchickey
left a comment
There was a problem hiding this comment.
Thanks, this is very nicely commented code
This was referenced Apr 17, 2024
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Jun 18, 2024
This commit is an implementation of component model semver compatibility for export lookups. Previously in bytecodealliance#7994 component imports were made semver-aware to ensure that bumping version numbers would not be a breaking change. This commit implements the same feature for component exports. This required some refactoring to move the definition of semver compat around and the previous refactoring in bytecodealliance#8786 enables frontloading this work to happen before instantiation. Closes bytecodealliance#8395
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 18, 2024
* Implement semver compatibility for exports This commit is an implementation of component model semver compatibility for export lookups. Previously in #7994 component imports were made semver-aware to ensure that bumping version numbers would not be a breaking change. This commit implements the same feature for component exports. This required some refactoring to move the definition of semver compat around and the previous refactoring in #8786 enables frontloading this work to happen before instantiation. Closes #8395 * Review comments * Fix tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit is an implementation of #7860 for Wasmtime where
wasmtime::component::Linkeris now "semver aware". This means that it assumes that hosts are always managing WIT interfaces in a semver-aare fashion meaning that semver-compatible upgrade exclusively adds functionality. This neatly fits into the idea of subtyping at the instance-level where if a binary built against 0.2.0 only requests a subset of functionality from a runtime that provides 0.2.1, that should work just fine.Specifically what this change does is:
For all names inserted into a
Linkerthere might also be a "semver compatible name" which is registered as well. For example[email protected]is also registered as..@1.Semver-compatible names are only provided for versions without a prerelease and with either a nonzero major or minor version number.
When looking up an item in the linker if no exact match is found then if a semver-compatible-name is available for the lookup key then that's consulted as well.
This semantically means that if a components imports WASI 0.2.0 then a runtime which only provides WASI 0.2.1 will be able to instantiate the component. Furthermore if a component imports WASI 0.2.1 but only imports the subset of WASI that was available in 0.2.0 then it will be instantiable in a runtime that only supports 0.2.0.
This implementation is intended to be a crucial part of the evolution to WASI to make it more seamless to upgrade WASI from both a host and guest perspective. This no longer requires everyone to upgrade to the same version all at the same time but instead decouples the upgrade schedules.
Closes #7860