Releases?

[GordonSmith]

It would be useful if this repo had releases + versions, especially for the ABI.

[lukewagner]

Yes, that's a good point. We're addressing this now by saying that (1) we're not making breaking changes to the binary format or Canonical ABI and (2) anything that is not part of 0.2 is gated by an "emoji" beside it (particularly in Binary.md, where it provides a pretty clean cut point). But once we get to 0.3 (and ungate the next batch of features), it would definitely be helpful to have tagged releases to classify what came in with 0.2 vs 0.3 (and probably before that too).

[av1934413]

It would be useful if this repo had releases + versions, especially for the ABI.

🔥

[andreaTP]

Old but gold 🙂
@lukewagner @alexcrichton do you have any guidance around pinning a specific version of this repository?

Things are moving a lot recently, and tracking the changes in our exploration of CM is starting to cause a little friction.

Having "Milestones" tagged in this repo would be helpful.

[alexcrichton]

The closest equivalent I'd recommend is the proposed process for WASI where WASI versions will incorporate component model features (in the future), and conequently the versioning would be "if you say you support WASI 0.X.Y it means you must also support this set of component-model features". That's still not fully finalized yet, however, so it may not help much in the meantime.

Could you expand on the friction you've been feeling recently? There's been churn in tests and text syntax, and that's one where I think Luke and I mostly assumed that there weren't all that many consumers of the preexisting tests. There could be a more relaxed transition period for tests and/or more embedder feedback for changes like those. In general though the text format is seen as much more malleable than the binary format (which shouldn't be changing for anything "stable").

Otherwise anything non-emoji-gated shouldn't be changing too much behavior-wise except in what's expected to be esoteric edge cases. The spec's reference implementation evolves as necessary, but it shouldn't be necessary to keep up too much with engines.

Anyway, those are some examples, but if you've got other instances of friction it'd help at least me thinking about this

[andreaTP]

We use wasm-tools json-from-wast to generate tests from the spec test suite.

Two concrete friction points:

1. Adding/removing a .wast file breaks our CI. We require every file in the test suite to be explicitly listed as either included or excluded to have no silent gaps. When a file is added or removed upstream, our build fails until we update the lists. This is by design on our side (we don't want to silently miss new tests), but it means every upstream change requires a downstream commit.
2. The recent test suite reorganization (wasm-tools/ and wasmtime/ dirs removed, tests moved to validation/, binary/, values/, etc.) combined with new WAT syntax (implements, inline realloc (core func ...)) broke compatibility with wasm-tools 1.246.0. We had to jump to 1.254.0 to parse the current test suite. An ~4 month gap in wasm-tools versions made the entire test suite unparseable.

Neither of these is a major problem individually, we just update. But tagged snapshots of the test suite would let us bump deliberately rather than discovering breakage on main. Even something lightweight like tagging alongside wasm-tools releases would help.

[alexcrichton]

For (1) I'd recommend using a pinning strategy to avoid CI breakage, for example we use git submodules in Wasmtime. You're right that this increases the likelihood that an upstream change isn't accounted for, but in mind mind that's a reasonable price to pay for deterministic CI which at least I personally value very highly. For (2), that's also something where I think pinning would help. That way when updating the submodule/commit that'd be the location to pull in an updated wasm-tools as well.

Effectively I guess what I'm saying is that tagged snapshots right in the component model's development is more-or-less git commits anyway. That has the same properties of letting you freeze tooling/expectations/etc while also enabling discrete updates on demand. The downside to this is that there's no shared understanding between projects of which commits are significant (unlike tags). This downside though sounds orthogonal to the friction you're experiencing currently, and that's also where at least in my opinion given the component model's development this sort of shared understanding between projects basically isn't necessary yet -- the core primitives of the component model have been left unchanged for years so any runtime implementing anywhere in the last year's worth of commits to this repo can probably all run wasip2 components.

[andreaTP]

Thanks for the guidance.
Agreed, pinning sounds like the best option with the current state of things.

I'd still value having tags in this repo when you think is appropriate to set a milestone, instead of going from commit to commit SHAs, this will give a sense of how much drift is being accumulated for people not strictly monitoring this repo.