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
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. #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?
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.
@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.
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.
Activity
lukewagner commentedon Jun 22, 2023
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.0now and follow the usual pre-1.0 semver rules (bumping minor version on breaking change, patch on non-breaking), saving1.0.0for when the proposal gets properly standardized. How does that sound to other folks?pchickey commentedon Jun 22, 2023
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?
brendandburns commentedon Jun 23, 2023
@pchickey would you like me to file a new issue there? I see that things like this have been discussed before e.g. #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
wasmtime9.0.0 as 0.1.0 and when 10.0.0 comes out I'll move to 0.2.0 etc. Sound good?brendandburns commentedon Jun 23, 2023
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-bindgeneverywhere, so I'd favor us releasing the client bindings as part of the release.lukewagner commentedon Jun 23, 2023
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.
eduardomourar commentedon Jun 23, 2023
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.
pchickey commentedon Jun 27, 2023
I've made this an agenda item to discuss at this week's WASI meeting: WebAssembly/meetings#1309
brendandburns commentedon Jul 16, 2023
@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.
pchickey commentedon Jul 17, 2023
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.
brendandburns commentedon Jul 17, 2023
Cool that looks good to me.
Part my desire to get this done is that I've been implementing
wasi-httpinwasi-goand also to make sure that various examples I write are targetted correctly.