You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 17, 2022. It is now read-only.
What will versioning for interface types look like? I recognize this is a can of worms and I'm exploring ways to avoid versioning myself, e.g. serialize complex structures that may have versioning differences similar to graphs in wasi_nn.
Because interface types are affine, this makes the problem perhaps more interesting than first glance.
A common approach to versioning in general is to attach a version field and have helpers manage deprecation or upgrading to a newer model. When linking wasm modules, something will need to recognize the version of a type and only link the latest version (one of many potential resolutions). Other ecosystems may have a package manager (wapm maybe?) that manages dependencies so at link time there is only one resolved version.
Another approach is for the ABI to have a major version attached to the signature, e.g. "myvariant_v2".
I hope all of the above approaches act as a decent straw man for something better :)
The text was updated successfully, but these errors were encountered:
That's a good question. I think, in general, versioning is a problem that needs to be solved at a higher level, such as the build tools that perform semver resolution and are aware of the package registries involved and have access to their version metadata.
That being said, it's useful to ask what Interface Types can do to support these tools. The biggest thing I'm aware of is that Interface Types should allow coercive subtyping between imports and exports (as described in this section) so that new minor semantic versions that backwards-compatibly extend an existing signature (e.g., by adding a new optional field or accepting a new variant case) can be type-compatible with imports of the previous version's type. Otherwise, what would logically feel like a minor version upgrade would actually be breaking and thus unnecessarily cause the version change to be major.
Separately, when it comes to encoding version information in modules, one option is to simply put the required major and possibly minor version in the import string. This approach is described in the context of shared-everything library linking here, but the technique can be applied just as well to shared-nothing linking.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What will versioning for interface types look like? I recognize this is a can of worms and I'm exploring ways to avoid versioning myself, e.g. serialize complex structures that may have versioning differences similar to graphs in wasi_nn.
Because interface types are affine, this makes the problem perhaps more interesting than first glance.
A common approach to versioning in general is to attach a version field and have helpers manage deprecation or upgrading to a newer model. When linking wasm modules, something will need to recognize the version of a type and only link the latest version (one of many potential resolutions). Other ecosystems may have a package manager (wapm maybe?) that manages dependencies so at link time there is only one resolved version.
Another approach is for the ABI to have a major version attached to the signature, e.g. "myvariant_v2".
I hope all of the above approaches act as a decent straw man for something better :)
The text was updated successfully, but these errors were encountered: