Comment by deathanatos | Hacker News Reader

Comment by deathanatos | Hacker News Reader

Good Lord. I'm going to paraphrase, since it's late and the gist doesn't really lay out a rational set of arguments.

"Not all projects use it!" Well, no, getting universal adoption of an idea is hard? That's not SemVer's job or fault.

"I don't have a well defined API, so what is a breaking change?" SemVer is going to be the least of your user's concern; the ill-defined API is going to hurt more when inevitable breakage leads to squabbles as to what is or isn't part of the API.

"SemVer won't save you from mistakes" Well… no, of course not. That's not the point. Mistakes happen. But it gives me, a developer, an idea of what to expect from an upgrade. In basically every other versioning scheme, I have to assume that any and every upgrade might include intentional breaking changes. With SemVer, I have an expectation: this shouldn't break changes. (But that's no substitute for testing, of course.)

"You should write a changelog instead!" You should just write a changelog too. If you're doing SemVer well, I might never need it, but if something accidentally breaks I'll want it. Without SemVer, I don't have a choice: I need that changelog to try to assess what could have been communicated in the version number had you used SemVer: is this a breaking change?

SemVer adds meaning to a version number; that meaning can be used to derive useful information, either as a machine or a human: that this change will break things.

Ideally, when a maintainer chooses to cause breakage, it can be small, minimal, and with a clearly communicated upgrade path (that ideally can be automated with tooling). The major bump tells me I might need to adjust my side / consumption of this dependency.

Since the article suggests nothing else in place of SemVer… most other schemes are date based (not relevant information to encode?) or just bump random numbers whenever they feel like it (Linux, I'm looking at you).

So much this. SemVer isn't perfect but it's a lot better than nothing.

In addition, generally speaking folks are pretty good at sticking to it. I've analysed the number from all the updates Dependabot makes to build SemVer compliance scores for packages (https://dependabot.com/compatibility-score/). Running across all packages for the Ruby ecosystem you get:

- Patch releases generally pass CI for 97% of their users

- Minor releases generally pass CI for 95% of their users

- Major releases generally pass CI for 85% of their users

It's not a perfect system, and library maintainers should definitely keep a changelog too (https://keepachangelog.com), but it's a lot better than nothing, or any of the alternatives.

Dependabot is great, and I love these statistics too :)

Do the above stats for patch and minor releases ignore 0.* releases?

They do, yep - only post 1.x releases are included.

Thanks :)

> SemVer adds meaning to a version number; that meaning can be used to derive useful information, either as a machine or a human: that this change will break things.

But it does not work like that in practice: people seem to be very fearful of being the guy who introduced a breaking change in a minor increment, so they increment the major whenever they are not sufficiently confident that there can't be a corner case where an API consumer would break. Since that corner case is almost universally possible (e.g. your new API extension's names might collide with names an API consumer might have foolishly declared under your namespace) the mindset of "when in doubt, increment major" dominates. The practical outcome of semver is that the important distinction between "chances are your app will be fine after the upgrade, no promises though" and "you might actually have to rearchitect a bit" has been completely lost.

> people seem to be very fearful of being the guy who introduced a breaking change in a minor increment, so they increment the major whenever they are not sufficiently confident that there can't be a corner case where an API consumer would break

Again, see the point about not having a well-defined API. (Again, this is taking issue with SemVer when you're not actually practicing it. But let's say I bend the rules a bit: what you suggest is fine, really. If you inadvertently bump a major and describe what the change is s.t. I can account for whether it breaks me — that's ok. As good as what SemVer wanted, no, but still better than just arbitrary versioning. There's likely still some subset of changes that you can reasonable assume are non-breaking. A commit that does linting only? Not going to break your API.)

> Since that corner case is almost universally possible (e.g. your new API extension's names might collide with names an API consumer might have foolishly declared under your namespace

In the few languages where this is possible, it is almost always implicitly not part of the API. E.g., in Python… if you're monkey-patching members/attribtes inside another package and that causes breakage — SemVer is not your problem here. You're going to have issues under any versioning scheme.

Reply on news.ycombinator.com