Skip to content
This repository has been archived by the owner on Aug 17, 2022. It is now read-only.

interface types versioning #139

Open
ricochet opened this issue Aug 26, 2021 · 1 comment
Open

interface types versioning #139

ricochet opened this issue Aug 26, 2021 · 1 comment

Comments

@ricochet
Copy link

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 :)

@lukewagner
Copy link
Member

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants