Stability of wasm-bindgen-cli-support

[rukai]

The wasm-bindgen-cli Cargo.toml specifies an exact version for wasm-bindgen-cli-support which suggests that the rust API for wasm-bindgen-cli-support doesnt follow semver

wasm-bindgen/crates/cli/Cargo.toml

Line 29 in 8aa58ac

wasm-bindgen-cli-support = { path = "../cli-support", version = "=0.2.78" }

Does it follow semver or not? (and I mean the informally agreed semver where 0.x.y means x is breaking and y is non-breaking)

If the rust API doesnt follow semver that would be really unfortunate and make it borderline useless for scripting wasm builds in rust as the patch version needs to be able to update freely to keep in sync with the wasm-bindgen version. e.g. https://github.com/rukai/cargo-run-wasm

[gthb]

Does it follow semver or not?

Seems in line with the actual semver which says:

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

So until a crate declares major version 1, pinning to an exact version of it is following exactly what its major version implies.

(and I mean the informally agreed semver where 0.x.y means x is breaking and y is non-breaking)

This “informally agreed semver” ... who informally agreed to that? :-)

Seems to me that it's best for clarity if:

1. If a project wants to communicate that its subminor version updates are non-breaking, then it declares a major version ≥1
2. If it doesn't, then it can keep its major version at 0
3. If it wants to have a major version of 0 (to suggest “this is immature stuff, folks”) but still promise that subminor updates have no breaking changes, then it should communicate that explicitly (because semver doesn't implicitly) — and if it doesn't, then, well, it doesn't. :-)

If it doesnt follow semver that would be really unfortunate and make it borderline useless for scripting wasm builds as the patch version needs to be able to update freely to keep in sync with the wasm-bindgen version. e.g. https://github.com/rukai/cargo-run-wasm

Hm, but aren't wasm-bindgen and wasm-bindgen-cli versioned and released in tandem, living in the same repo as they do? Maybe I'm just slow — can you explain the problem more clearly?

[rukai]

This “informally agreed semver” ... who informally agreed to that? :-)

I cant name a single crate that doesnt follow this. It would be complete chaos if they didnt given all the pre 1.0.0 crates in the ecosystem.

I would be very surprised if wasm-bindgen itself wasnt following this.

If it wants to have a major version of 0 (to suggest “this is immature stuff, folks”) but still promise that subminor updates have no breaking changes, then it should communicate that explicitly (because semver doesn't implicitly) — and if it doesn't, then, well, it doesn't.

The informal semver agreement is actually so common that I would expect the opposite.
If wasm-bindgen crates want to include breaking changes in patch releases then I would expect that to be documented.

Hm, but aren't wasm-bindgen and wasm-bindgen-cli versioned and released in tandem, living in the same repo as they do? Maybe I'm just slow — can you explain the problem more clearly?

The problem is the stability of the rust API of wasm-bindgen-cli-support.
Compatibility with wasm-bindgen releases is not my concern.

For example its used here:
https://github.com/rukai/cargo-run-wasm/blob/0dce868c851306655fd312f3c59454ce788a92e0/src/lib.rs#L140
If this API is changed on a patch release that would break the linked crate.

Thinking about it the exact version dependency might be used for wasm-bindgen/wasm-bindgen-cli compatibility reasons instead of rust API compatibility reasons. But I'd still like to hear from someone like @alexcrichton about this though.

[chinedufn]

Thinking about it the exact version dependency might be used for wasm-bindgen/wasm-bindgen-cli compatibility reasons instead of rust API compatibility reasons.

Yeah.

Some context on why exact versions are used across wasm-bindgen can be found here #2544 .

tl;dr - it ensures that all of the crates are using the same wasm-bindgen data format since the data format used to change a lot.

These days the data format doesn't really change much (maybe once a year at this point)? I don't know whether or not that is indicative of future stability though.

[madsmtm]

The Cargo documentation specifies this informal convention / spec extension (and the dependency resolver assumes that it holds):

This guide uses the terms "major" and "minor" assuming this relates to a "1.0.0" release or later. Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.

(Highlight mine)

[rukai]

Ok, well if its purely for the data format and pinning the exact version isnt abused for making breaking rust API changes then that's perfect.
Please close this issue if you confirm that to be the case.

[alexcrichton]

Yes this is indeed an internal crate and it does not follow semver. The version just matches the wasm-bindgen-cli version (and wasm-bindgen) for convenience. Otherwise though it's also useful for ensuring wasm-bindgen is only at one version in a project as mentioned already here.

[rukai]

Ah, good to know.

Wasm-bindgen-cli exposed as a rust API would be really valuable to cargo-run-wasm and by extension winit and wgpu.

What are your thoughts on one of these:

• Promote wasm-bindgen-cli-support to a public crate and have the API follow semver
• Create a new frontend crate that exposes wasm-bindgen-cli-support as a stable rust API

[alexcrichton]

I would first primarily recommend using the CLI if you can, since that's the intended way to run things. Otherwise though the wasm-bindgen-cli-support crate is already designed to look very similar to the CLI, at least in theory, so there's nothing preventing you from using it directly (it should basically already be usable if you'd like to use it). I've basically never designed the crate for "official" external consumption so it doesn't have documentation and may be lacking something here and there.

[rukai]

so there's nothing preventing you from using it directly

Except for the fact that you said it does not follow semver.

I guess I could use an exact version dependency.
But if I pin the wasm-bindgen-cli-support crate version then the data format version will get out of sync.
In my use case a workspace is used such that the Cargo.lock is shared between wasm-bindgen and wasm-bindgen-cli-support.
So if I had access to a stable wasm-bindgen-cli-support then I could ensure breakage never happens. No rust API breakage and no data version breakage.

This is why I would like a stable API for this, is this something wasm-bindgen can provide? As one of the suggestions in the previous comment or maybe something else entirely?

[alexcrichton]

Sorry but at this point I'm not really prepared to commit to a stable API of internal crates at this time. I'm barely hanging on as-is and adding yet-more to my plate I don't think I'm up to the task for.

[rukai]

That's all good just needed to know the situation. thanks for your efforts!