Consistent version syntax

[sunfishcode]

Currently, WIT package names put the version after the package name:

package wasi:http@2.0.0;

However, WIT use statements and similar things put the version after the interface:

use wasi:http/types@0.2.0.{incoming-request};

Similarly, import/export strings also put the version after the interface:

(import "wasi:http/types@0.2.0" (instance (;0;) (type 0)))

These lead me to sometimes be confused about whether to say wasi:http@0.2.0/types.{incoming-request} or wasi:http/types@0.2.0.{incoming-request}. I've been trying to get used to it by telling myself that package wasi:http@2.0.0; is syntax-sugar for adding the version explicitly to all of the contained interfaces, but I still get confused. It doesn't help that interface types@0.2.0 { isn't valid in WIT, and I don't expect it ever will be.

And, wasi:http/types@0.2.0.{incoming-request} suggests a misleading mental model, as if wasi:http were a thing that gets looked up without a version, and then types@0.2.0 is a versioned thing to look up inside that.

Additionally, types@0.2.0.{incoming-request} is awkward with a . immediately after the .-separated semver syntax, looking to a first glance like it might be part of the version.

I propose changing WIT and components to use the wasi:http@0.2.0/types.{incoming-request} form, pre-1.0 when we have an opportunity to make a breaking change.

[lukewagner]

That's a good point and I've wondered whether we should do that too. I'd be open to the change and it does seems like a good thing to discuss including as part of the 1.0 binary format breaking changes.

[tschneidereit]

This always felt off to me as well, but I couldn't articulate why quite as clearly as laid out here—thank you for that!

To enable adoption of the proposed format, would it be possible to support both, and then eventually deprecate the current format? We could then disallow it for at least WASI interfaces with versions >= 1. (We could consider disallowing it for all interfaces with versions >= 1, but that'd certainly break some existing uses, so would at least need more care.)

[badeend]

I think this touches the same underlying problem of #231, albeit with a different proposed solution.

One issue is that the use syntax uses the . separator, and at the same time also defers to the semver standard for the version number format. But semver also has its own (different!) meaning for .
An example from #231:

use example:http/client@1.0.0-beta.nginx.{ request, response }

// It may look like we're "drilling into" some sort of `nginx` submodule
// of the `example:http/client@1.0.0-beta` package, but actually `nginx` is part of the
// semver 'prerelease' component.