-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Properly supporting semver, plus -DRAFT
releases of packages
#8029
Comments
At a high level one of the goals I'd like to have with our WASI support in Wasmtime is that we're not required to keep an ever-expanding list of copies of WASI APIs, e.g. 0.2.0, 0.2.1, 0.2.2, .... If we take this as a goal, however, I don't think that we can solve problem (1) listed above because WIT itself doesn't retain a version number of when a symbol was first defined. Personally I don't think this matters too much in the sense that you would have to really go out of your way to create a component that imports 0.2.1 APIs at an 0.2.0 version and there's not necessarily a big consequence. Additionally with adding a symbol to each semver range, if we take the above goal as one to pursue, I'm not sure how we would do that. I'm not sure how we could enumerate all the semver versions that a symbol was known at. Otherwise though in terms of how the The semver compat stuff at this point is currently all built where for each component instance in the tree there's a table in that instance of "if you're looking for something semver compatible with 0.2.X then go load import 0.2.3" (or whatever the max registered version is). That's what gives rise to the behavior of if you import timezones at 0.2.0 then you'll get a "hit" on timezones at 0.2.1. I explain the Speaking again at a high level in terms of requirements, I think another requirement we'd like to have is to avoid the need to have lots of "implement this one WASI proposal in terms of this other one". For example in Wasmtime we don't want to manually implement all of 0.2.0 in terms of 0.2.1. Now in terms of trying to propose a solution instead of just critiquing them: the best I can think of is to maintain the last stable WASI release and the next draft we're supporting. This would then look like:
Then as part of the ecosystem we'd have an optional feature perhaps on the |
I'll note though that my proposed idea does not solve (1), it leaves it as an open problem to be solved in the future, if at all |
In the Wasmtime meeting today, we discussed some challenges around semver support for component model packages.
Specifically, we identified two issues:
During the meeting, I proposed an approach that'd involve maintaining a side-table of symbols to add to the linker under aliases, where for each minor version we'd add all current contents of the side table to the linker aliased for that version, and additionally add all symbols introduced by that version to the table (and the linker.)
I think we could abstract that away by introducing methods on the linker along the lines of
start_semver_range
add_to_semver_range
(which would invokeadd_to_linker
)end_semver_range
As a concrete example, say we want to support versions
0.2.0
,0.2.1-DRAFT
,0.2.1
, and0.2.2
of a package. (Setting aside the question of whether we'd ever want to support a-DRAFT
version in parallel to the respective stable version or any higher minor versions.) This approach would have us follow these steps:start_semver_range
add_to_semver_range
for each symbol in0.2.0
add_to_linker
(❗) for symbol in0.2.1-DRAFT
add_to_semver_range
for each symbol in0.2.1
add_to_semver_range
for each symbol in0.2.2
I'm not particularly familiar with the workings of Wasmtime's linker, so this might not work all that well in practice—but maybe it does?
The text was updated successfully, but these errors were encountered: