[jjnoakes]

Perhaps, but he repeatedly claimed that the minor and patch numbers conveyed no meaning, while dismissing the semver spec as a manifesto.

But if he read and understood it, he'd know those were important numbers. Maybe moreso than the major version.

Perhaps he should have argued his actual stance more, instead of the strawman stance. That put me off.

[sheepmullet]

From the point of view of a library consumer why should they care about the patch or minor versions at all?

Isn't later = better?

[jjnoakes]

Because if you start relying on something new or fixed in x.2.z of your dependency you want to make sure anyone using your code isn't using x.1.y.

[sheepmullet]

And doesn't automatic dependency resolution make this a non-issue for your consumer?

Edit: I.e. If you declare your own dependencies then tooling should ensure anyone who uses your code uses the same dependencies.

It doesn't work this way in Java world due to technical limitations, but it can in JS world

[jjnoakes]

Consumers may want to use a different version.

Perhaps they want a newer one (bug fix, security fix).

Perhaps they want an older one (since another dependency was tested against an older version of the dep in question).

Semver gives you a way to decide what ranges of versions should be safe to move between in order to satisfy all of those occasionally conflicting requirements.

[sheepmullet]

Explicitly limiting your consumers to a specific version of another library is a breaking change. You have introduced a very specific dependency and are requiring the consumer to honour it.

By semvar rules you should be updating the major version?

[jjnoakes]

What?

If my library requires X version 1.2 or higher, how is it a breaking change if I don't work with version 2.0 or 1.0 or anything except 1.2 through 1.99999?

That's the whole point of software versioning, no matter what you call it (renaming things, semver, git hashes, anything). At some point you require something of someone else, and you can only use the versions of that other library which provide what you require (or more). Semver is just a way to lock those requirements into a machine-readable number scheme.

[prodigal_erik]

That limitation is healthy. If versions 1.1 and 1.2 of a class exist and I'm foolish and determined enough to use both in the same process (via multiple classloaders), Java will still ensure that I can't accidentally give a 1.1 instance to a callee expecting a 1.2 instance, or vice versa. Version mismatches at call sites fail quickly and loudly with classloading exceptions.

I think a hell of a lot of NPM packages only appear to work by accident, and over time they'll fail because of sloppiness about this.