Skip to content
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

RFC: WIT-Bindgen Versioning and Release Process #26

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

esoterra
Copy link

This RFC proposes a versioning policy and release process for the wit-bindgen project built around Release PRs where a Release Lead updates changelogs and generates new version numbers for each crate to be released. This process enforces the use of Conventional Commits by all contributors to enable tooling to automate much of the process of creating Release PRs.

@esoterra esoterra marked this pull request as draft June 28, 2022 17:59
@alexcrichton
Copy link
Member

Thanks for taking the time to write this up, but as I read over it at least personally the main impression that I get is that this is a lot of work and process for not a lot of gain. These sorts of things seem good to write down eventually in the future but for now it feels to me like we have much bigger issues in wit-bindgen around issues like:

  • The component model is still a moving target that wit-bindgen hasn't caught up to. There's significant divergence in the current implementation of async/futures/etc between the predicted path of the component model and wit-bindgen as-is today.
  • In wit-bindgen features like resource types don't even exist in the component model yet.
  • Support for streams in wit-bindgen doesn't exist beyond parsing, and it's unclear how this will play out in each language.
  • The interface of wit-bindgen itself ("what exactly do you write down") in terms of what are the inputs and what are the outputs is itself still in flux.

Overall this seems like the wrong time to add process to a situation that mainly needs foundational work to make progress. Unfortunately this work isn't just exclusive to wit-bindgen as there's a lot of coordination that also needs to happen with the component-model proposal, various consumers, etc.

Reflecting on this now I'm personally thinking that it would be better to flesh out wit-bindgen itself and its implementation before going much further down the path for a release process and versioning and such. For example with Wasmtime first the API had an RFC and afterwards there was a Wasmtime 1.0 RFC. This sort of feels like the inverse order of operations is happening for wit-bindgen and I think that's at least one reason this feels premature aftering seeing it laid out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants