Rich Hickey's take on SemVer makes for a really fantastic talk.

"Change isn't a thing. It's one of two things: Growth or Breakage." Growth means the code requires less, or provides more, or has bug fixes. Breakage is the opposite; the code requires more, provides less, or does something silly like reuse a name for something completely different.

I recommend the whole talk, but the specific beef about SemVer starts here: https://youtu.be/oyLBGkS5ICk?t=1792

While the distinction of construct vs contract is subtle, improved tooling will eventually elevate the "construct" to a contract.

semver needs to be combined with a package manager and strong version locking semantics for it to be useful.

Both npm and yarn in the node eco-system certainly provide this - with any remaining kinks are being ironed out fast.

Using micro-modules as dependencies is a rather pleasant experience in node/js - especially when the dependencies follow semver. This is even more true of popular modules, where authors take their versioning responsibility seriously.

I regularly use automated version updates (npm-check -u [1]/ npm audit --fix [2]). Coupled with good test coverage of my code, I've been really happy.

[1] https://www.npmjs.com/package/npm-check [2] https://docs.npmjs.com/getting-started/running-a-security-au...

>SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it.

Whats the solution here? Fuck standards? Imagine if we had that same attitude with regards to HTTP.

I've found that the golden rule of "everyone is lying to you" works well enough. Assume that every change will be a breaking change. Test everything, verify everything, and then continue to test and verify when it's in production.

I've never found standards to be all that standard.

I haven’t figured out how to implement this, but the key observation is that Semver is trying to delineate degrees of substitutability (LSP).

I think the right solution here is to build version numbers off of your black box tests.

The devil is in the details though. What’s a change to the tests mean exactly? Adding new tests is probably a patch release. Modifying tests demands at least a minor version number, but what makes it a major version number? Deleting tests probably qualifies. Removing assertions probably does too.

But now what if the author is bad at tests too? Can I substitute my own? (I could do that right now for regression testing, and in fact I do occasionally for interdepartmental issues).

> Imagine if we had that same attitude with regards to HTTP.

Well, many do. You wouldn't believe the number of broken HTTP clients/servers out there.

The difference is that most HTTP clients/servers have to work with some significant subset of the pre-existing HTTP infrastructure (otherwise why would anyone use them?) and so that constrains their implementation to be "mostly correct". It's literally network effects :).

Libraries on the other hand usually start out with a single consumer and have no such constraints on their implementation so you end up with various levels of ossified brokenness or breaking non-ossification.

SemVer is a starting point. If it's a major release you can prepare yourself mentally for a lot of breaking changes. A point release... probably not

In any case you need to read through the changelog or (absent that) the actual code diff and think about how you use the application. It's not 100%, but no versioning system will be able to identify how you use code and how you expect the semantics of an application to be.

The issue is that because not everyone follows SemVer, you have to assume that no-one follows SemVer and act defensively, otherwise you will have problems.

Ideally, there would be a tool that can inspect your entire codebase and determine if the change is "breaking". This still has issues if the change lies outside of your codebase (perhaps such as changing the configuration of your AWS services).

A good idea ia to treat every change as a major change.

Or use ComVer

https://github.com/staltz/comver/blob/master/README.md

A problem with SemVer I often see is that it's unclear whether a project adheres to it. You just can't assume every project having x.y.z version numbers uses semantic versioning.

If the version number is less than 3.1, odds are very good they don’t.

And I just described 80% of the node module ecosystem...

Not necessarily. There are plenty of projects in their infancy that follow semver correctly. I'd argue that a project with a high major number is more likely to be indicative of improper usage.

I don’t think high major version number tells you that. Maybe they left 0.x.y (unstable) too early and were just honest with their early churn since which is as semver as you can get.

But one if the main semver violations I see in the wild is a project slotting major changes into the minor version number because they want to avoid high major version numbers for some reason or have some romantic idea of what a major version bump “should be”.

A lot of people do not respect HTTP standards. We've all seen or heard of APIs returning the infamous HTTP 200 { error: true, errorMessage: "..." }

That's not disrespecting HTTP standard. That's the consequence of using HTTP in place of a proper RPC protocol.

Build numbers is engineering, semver is marketing.

Private processes vs what you tell the world.

Build numbers unlocks delta debugging achievement. Add 'last known good' and 'found' build numbers to tickets, along with repo steps, then use diff to find bug.

Build numbers also unlocks QA/testing achievement. Add 'found', 'fixed', 'verified' fields to tickets. Now your team is certain when individual changes are ready to merge, ship/deploy.

Contracts are social constructs too.

In programming, type contracts are not. Wouldn't it be nice if we had some sort of infallible static analysis tool that absolutely determines what constitutes a breaking change in your codebase?

Exactly, every change is breaking for someone: https://xkcd.com/1172/