WebAssembly
Versioning/Tagging?
With the wasi-http spec continuing to iterate, does it make sense to tag specific versions so that guests/hosts can align on what to expect?
Yeah, now that we have versions fully supported in Wit, that would make sense to me to start using it to help coordinate our implementations. I suppose we can just switch to 0.0.0 now and follow the usual pre-1.0 semver rules (bumping minor version on breaking change, patch on non-breaking), saving 1.0.0 for when the proposal gets properly standardized. How does that sound to other folks?
I agree we should tag everything with pre-1.0 semver at this time. We can use git tags and GitHub releases to publish those for now, and add a registry publish to the release process as well once the registry and tooling are sufficiently stable.
We want a process we can follow uniformly across all wit-based WASI proposals. So, can we move this discussion over to https://github.com/WebAssembly/WASI, settle on a process that we'll implement in the template repo, and then roll out here and elsewhere?
@pchickey would you like me to file a new issue there? I see that things like this have been discussed before e.g. https://github.com/WebAssembly/WASI/issues/29 so I don't want to file a redundant issue, but if this is different, I'm happy to start something in that repo.
Meanwhile, what do you think about tagging the wit that merged into wasmtime 9.0.0 as 0.1.0 and when 10.0.0 comes out I'll move to 0.2.0 etc. Sound good?
Also, do we want to release the client bindings as part of a version? Or do we expect people to generate those themselves.
I'm finding it kind of annoying to require installing wit-bindgen everywhere, so I'd favor us releasing the client bindings as part of the release.
For the release of bindings, it seems like we'll have lots of different language bindings that can vary independently (as the bindings generators are changed or parameterized), so committing them all to the WASI proposal repos doesn't sound like the right place. Instead, I think it's the per-language toolchain that will roll bindings generation into a higher-level workflow to make it automatic for the developer.
For the Rust client binding, it would nice to have an automated process and have that be a reference implementation. We should revisit something similar to this PR.
I've made this an agenda item to discuss at this week's WASI meeting: https://github.com/WebAssembly/meetings/pull/1309
@pchickey @lukewagner was there any consensus on an approach here? I think this is definitely needed if we want people to actually start using these interfaces. People can't take dependencies on a moving target.
I made this presentation: https://github.com/WebAssembly/meetings/blob/main/wasi/2023/WASI-06-29.md#pat-versioning-of-pre-release-proposal-wits and I will be adding it to the WASI repo documents soon.
Cool that looks good to me.
Part my desire to get this done is that I've been implementing wasi-http in wasi-go and also to make sure that various examples I write are targetted correctly.