rustwasm
Change Semver so deprecation warnings can be handled better?
Motivation
I was using a client-side framework that imported wasm-bindgen and it threw several deprecation errors despite having wasm-bindgen = "0.2.87" specified in several Cargo.toml files. I feel like this might be because wasm-bindgen is shipping deprecation and breaking changes with the "patch" incremented and not the "minor" incremented in the version number, but I'm open to being corrected here.
From semver.org:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Also:
https://semver.org/#spec-item-7 Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
Here's an example of one I fixed:
use of deprecated method `web_sys::AddEventListenerOptions::capture`: Use `set_capture()` instead.
`#[warn(deprecated)]` on by default
Proposed Solution
Long term, bump everything up a version class. Instead of "0.2.101" release as "2.101.0".
Because there are lots of crates out there depending on wasm-bindgen (2,228 as of this writing) it's likely best to do a dual-release of both of these version numbers for a number of months (say half a year to a year) and eventually drop updates to the "0" version.
It's common in our ecosystem to never release a version 1 (get_random is another example), for me it's due to perfectionism and if it's never 1.0 it's never really released 😄 . Because we're not bumping to 1.0 it means we're losing out on the power of semantic versioning for the consumers of our work.
Alternatives
Start using additional labels as a stand-in?
Additional Context
The MR that triggered this thought is here: https://github.com/wishawa/async_ui/pull/15/files
@RandomInsano All 0.x.y changes are formally considered MAJOR versions in SemVer.
Cargo adheres to a deviant understanding of SemVer which proposes that a 0.x.y to 0.x.(y+1) change is a MINOR version.
It is likely, however, that you have encountered warnings because wasm-bindgen ~0.2.89 is ABI compatible with the tool conventions extern "C" ABI, instead of rustc's "invented" C ABI, and rustc intends to fix the wasm target to actually be compatible with the real C ABI for wasm. This means that earlier versions of wasm-bindgen will produce broken results on newer versions of rustc, even if they compile.
...Annoyingly, everything technically remains API compatible, and SemVer is mute about ABI compatibility, so technically there is no SemVer violation. I do not say this to dismiss the inconvenience you are experiencing, as I believe it is quite real and we are doing what we can to mitigate it. I am just noting that we really ought to come up with something other than SemVer, honestly.
Thanks for the info! I’m pretty surprised that Cargo follows a different understanding of SemVer. In practice for me it safely automatically upgrades to the latest “Y” in your example when I run cargo updatehttps://doc.rust-lang.org/cargo/commands/cargo-update.html (I’ll give this another read today)Is there some place I can read up on that more? I’m not even sure what I’d search for to find that info…Regards,EdwinOn Mar 14, 2025, at 10:37 PM, Jubilee @.> wrote:
@RandomInsano All 0.x.y changes are formally considered MAJOR versions in SemVer.
Cargo adheres to a deviant understanding of SemVer which proposes that a 0.x.y to 0.x.(y+1) change is a MINOR version.
It is likely, however, that you have encountered warnings because wasm-bindgen ~0.2.89 is ABI compatible with the tool conventions extern "C" ABI, instead of rustc's "invented" C ABI, and rustc intends to fix the wasm target to actually be compatible with the real C ABI for wasm. This means that earlier versions of wasm-bindgen will produce broken results on newer versions of rustc, even if they compile.
...Annoyingly, everything technically remains API compatible, and SemVer is mute about ABI compatibility, so technically there is no SemVer violation. I do not say this to dismiss the inconvenience you are experiencing, as I believe it is quite real and we are doing what we can to mitigate it. I am just noting that we really ought to come up with something other than SemVer, honestly.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.>
workingjubilee left a comment (rustwasm/wasm-bindgen#4419) @RandomInsano All 0.x.y changes are formally considered MAJOR versions in SemVer. Cargo adheres to a deviant understanding of SemVer which proposes that a 0.x.y to 0.x.(y+1) change is a MINOR version. It is likely, however, that you have encountered warnings because wasm-bindgen ~0.2.89 is ABI compatible with the tool conventions extern "C" ABI, instead of rustc's "invented" C ABI, and rustc intends to fix the wasm target to actually be compatible with the real C ABI for wasm. This means that earlier versions of wasm-bindgen will produce broken results on newer versions of rustc, even if they compile. ...Annoyingly, everything technically remains API compatible, and SemVer is mute about ABI compatibility, so technically there is no SemVer violation. I do not say this to dismiss the inconvenience you are experiencing, as I believe it is quite real and we are doing what we can to mitigate it. I am just noting that we really ought to come up with something other than SemVer, honestly.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>