[BugsJustFindMe]

The value of semver has always been a lie. https://news.ycombinator.com/item?id=37426532

Making you distrust updates is absolutely the correct versioning method. Pin your versions in software you care about and establish a maintenance schedule. Trusting that people don't break things unintentionally all the time is extremely naive.

It was dumb and user-hostile to remove an interface for no good reason that just makes it more work for people to update, but everyone not pinning versions needs to acknowledge that they're choosing to live dangerously.

[minitech]

In practice, semver is very helpful. Its major benefit is allowing packages to declare compatibility with versions of their own dependencies that don’t exist yet. (Distrusting updates and pinning versions is important and correct, but it’s not a “versioning method” that stands in contrast to semver or anything. That’s what lockfiles are for.) The pre-semver Python package ecosystem is a good example of what happens without it: fresh installs of packages break all the time because they have open-ended or overly permissive upper bounds on their dependencies. If they were to specify exact preexisting upper bounds, they’d slow down bugfixes (and in Python, where you can only have one version of a package in a given environment, new features) and add maintenance busywork; I’m not aware of any packages that choose this option in practice.

> You have released version 1.0.0 of something. Then you add a feature and fix a bug unrelated to that feature. Are you at version 1.1.0 or 1.1.1? Well, it depends on the order you added your changes, doesn't it? If you fixed the bug first you'll go from 1.0.0 to 1.0.1 to 1.1.0, and if you add the feature first you'll go from 1.0.0 to 1.1.0 to 1.1.1. And if that difference doesn't matter, then the last digit doesn't matter.

It depends on the order you released your changes, yes. If you have the option, the most useful order is to release 1.0.1 with the bugfix and 1.1.0 with both changes, but you can also choose to release 1.1.0 without the bugfix (why intentionally release a buggy version?) and then 1.1.1 (with or without 1.0.1), or just 1.1.0 with both changes. You’re correct that the starting point of the patch version within a particular minor version doesn’t matter – you could pick 0, 1, or 31415. You can also increment it by whatever you want in practice. All this flexibility is a total non-problem (let alone a problem with the versioning scheme, considering it’s flexibility that comes from which releases you even choose to cut – semver just makes the relationship between them clear), and doesn’t indicate that the patch field is meaningless in general. (Obviously, you should start at 0 and increment by 1, since that’s boring and normal.)

Sure, it’s impossible to classify breaking changes and new features with perfect precision, and maintainers can make mistakes, but semver is pretty clearly a net positive. (It takes almost no effort and has no superior competitors, so it would be hard for it not to be.)