What changes to WIT are "compatible" and which are not?

Open
#335 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
50/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet
Tech stack
wasm
Domain
documentation

Research direction

Start by reviewing the WIT compatibility scenarios listed in the issue and the linked Protobuf “Updating a Message Type” guidance. Document whether each of the six changes is compatible in the old-host/new-guest and new-host/old-guest directions, including the relevant conditions and limitations.

Written by the indexing model from the issue text.

Description

Suppose I have a WIT definition, and some old WebAssembly components built/defined using the old definition, and then I want to make a change to my interface without requiring the component to be modified or rebuilt. Or perhaps I want to do the same in the reverse direction—make a change to my WASM component that remains backward-compatible with a host using an older WIT.

What changes to the WIT could be considered "compatible", if any, and which are not?

In essence, I'm looking for guidance similar to what Protobuf offers in their Updating a Message Type documentation.

A few example questions/scenarios I can think of: are the following compatible in one or both directions (old host/new guest vs. new guest/old host)?

  1. Removing an argument to a function
  2. Adding a new optional argument to a function
  3. Adding a new optional field to a struct
  4. Removing a field from a struct
  5. Adding a new case to a variant
  6. Removing a case from a variant
Dominant language
Rust
Stars
137
Forks
88
Avg merge
10h 38m
Merged PRs (30d)
2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bytecodealliance/component-docs

All issues in bytecodealliance/component-docs

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.