Versioning is a facet of documentation. SemVer is not the only way, but it's a widely-understood convection and quite logical.

The core issue generally comes down to: "If I upgrade, what do I have to do?"

If you have good release notes and upgrade guide(s) that don't assume every user is following each release closely, that's probably ok.

If your release notes are non-existent or just an export of your commit messages or ticket titles, SemVer helps cut through the noise.

Going from 1.2.34 to 1.2.85? No second thoughts. To 1.5.2? I'll probably look at what was new in 1.3.0, 1.4.0 and 1.5.0 just to keep updated. To 3.2.0? I'm going to be super cautious and assume I have a bunch of changes to make, and hopefully there's a 1.x to 3.x guide, or at least 1.x to 2.x and 2.x to 3.x.

In the worst case, it compiles fine but a bunch of stuff breaks at runtime. With nothing but SemVer, I'm at least prepared to test extensively. If I go from 1.2.34 to 1.2.x and get a bunch of runtime breaks, my first reaction is going to involve profanity and be something along the lines of "time to replace this garbage library with something better."

As library authors, we're under no obligation to use SemVer, produce release notes, documentation, or do anything else. The nice thing about SemVer is it's basically zero-effort yet provides massive benefits to users, especially if everything else I mentioned is lacking.

Agreed.

SemVer is nice but not nescessarily - I'd rather a project not follow semver but have a clear deprecation cycle they follow all other things been equal.

version n, we are going to remove foo n+1 foo is marked as deprecated n+2 foo is removed.

That I can work with since it gives me a change to refactor with clear ideas of what will break.

The symfony team get my absolute respect for the way they handle this over in PHP land,it gives me a high degree of re-assurance that we can reliably shift versions with minimal friction since they are alerting me though deprecation notices that I can then go resolve.

The difference is that I can update all dependencies without having to verify whether they contain breaking changes, because I can just look at the number.

Conformism helps us think less. Imagine if every website had their own way of scrolling or logging in. Press T to login. Triple click here.

Semver helps me update 10 dependencies in 5 seconds without opening any release notes.

Developers are under no obligations, but one should not go out of their way to make others’ lives harder. Just use semver.

That is precisely what I mean about not materializing, reality is not like that. Maintainers make mistakes, are not diligent about following semver, and after enough “minor” upgrades that break everything you simply lose all trust in the numbers.

If you’re updating 10 dependencies in 5 seconds without really following along closely what exactly you’re updating and why, maybe don’t do that.

Not exactly 10 dependencies, but I do that many times by using version ranges like ^1.0.0. So to answer your question: What you are updating and why... mostly patch and minor versions that include vulnerability and performance fixes. And I read release notes... but the number gives me a good idea what to read in more detail.

Now the problem of TS not following the convention is that many projects have ranges like ^3.7.1 in their package.json without knowing that a simple install removing package-lock may break your build because 3.8 and 3.9 have breaking changes in it.

If it isn't for a meaningful versioning scheme, how is a version number useful at all? Why not just go version 1, 2, 3 and keep incrementing?

People can easily guess that patch version bump is safe to apply as it only fixes stuff and apply minor version bump if you want new features which won't break your current deployment and be cautious of any major version bumps.

Not that every semver oriented apps closely follow that but it does help users understand if they want to install the new version or not without digging the entire change log.