SemVer has failed us

Semver hasn't failed anyone--web developers and the bozos in the Node community (of which I cheerfully count myself as a member) are lacking in discipline.

You should be fast to get to 1.x.x. If your app breaks on a patch release (that was only a bugfix and provided that interfaces stayed consistent), maybe you shouldn't rely on buggy behavior and maybe you should fix your code.

This isn't a failing of semver--this is a failure of being responsible engineers.

EDIT:

The best example from the article is the bit talking about how people interpret 0.x vs 1.x vs 2.x. Folks, it's just a damned version number, and a number that only indicates you may have to refactor you application to handle changed interfaces. Any other psychological baggage you attach to it is just that, baggage. Aaaargh.

SemVer is working fine, you just need to face up to the real impact of a change on clients, not what you wish was the impact of the change. If a change breaks clients who rely on buggy behavior, you need to bump a version, not a patch number.

It's basically just semver, with a little more indication given to what sorts of breakages are considered. The problem I have with "minor" vs "major" breakage is that if I only use one function from your library, and it breaks and screws up my entire app, that ain't "minor".

This is just more of the same marking of territory that Node is kinda famous for.

We've used SemVer for Julia for a while now and it seems fine. However, versioning and compatibility are still hard problems and a perennial, unavoidable pain. The way I like to think of it is this:

- patch: forwards and backwards compatible – only bug fixes, no new features, no changing existing features.

- minor: backwards compatible – new features allowed, but old code should keep working.

- major: all bets are off.

This is pretty much what the SemVer spec says, and it's hard to imagine what else you could do. The significance of forwards compatibility for patch versions is that if you bump a patch version and find that it was problematic, you should be able to revert back to a lower patch version without breaking new code that's been written since the bump.

The thing is, it's still a judgement call what constitutes a bug fix. If you're fixing a segfault, that's a no brainer – no one (sane) was relying on something segfaulting. If you're changing a behavior from one potentially reasonable behavior to the one that was actually documented, then, yeah, that might not be "just a bug fix" – people might be relying on it. So we're super conservative about "fixing" even fairly bad behavior in patch releases. Still, the only way to make sure an application keeps working exactly the same is to use the same exact versions – down to the patch level.

The FerVer "spec" is barely coherent, I'm not sure how anyone could consider that something to follow. SlimVer basically just gets rid of things in SemVer that you don't have to use anyway. Pre-release versions – especially release candidates – are incredibly useful. You tag 1.2.3-rc1 and if no issues crop up in a week, then that becomes your 1.2.3 release (1.2.3-rc1 and 1.2.3 are exactly the same); if issues do crop up, then you fix them and tag 1.2.3-rc2 in a week and repeat.

I also think that pre-1.0 versions are useful: just treat the minor version like a major version. For 0.1.2 => 0.1.3 you only fix bugs but for 0.1.3 => 0.2.0 anything goes. There's no point in doing feature-only, backwards compatible releases while you're still working out the API for something, and 0.x releases are for precisely that kind of exploratory period.

Semver is busted because it makes builds non-deterministic. Building the same code tomorrow may fail if a third party dependency publishes a change violating semver.

For example: https://github.com/bower/bower/issues/1404#issuecomment-4876...

I unfortunately can only complain, I have no solution to offer.