Is Semantic Versioning an Anti-Pattern?

I think this talk makes his opinion on how breaking changes in libraries should be handled (in the context of the JVM ecosystem) very clear:

A) avoid breaking API changes

B) if you have to do large breaking API changes, that will probably affect alot of dependent projects, make it a new artifact / namespace / library that can live side-by-side with the old version

B is actually pretty common in large java library projects (rxjava -> rxjava 2, retrofit -> retrofit 2, dagger -> dagger ‡ all have independent maven artifacts and I think also packages) and imho this approach makes a lot of sense. It's also the more important part of this talk compared to his critique of semver.

Your problem has nothing to do with semver. The solution to your problem is to use your package manager's dependency freeze utility (npm shrinkwrap in your case), and also to select your dependencies carefully, so you don't end up with thousands of subdependencies (I know some npm packages suffer from dependency incontinence - this is a good reason not to use them).

> With modern CD systems, we want to simplify. Changes should be small and frequent, which leads to stable and gradual improvement without much pain. But this frequency itself becomes a counter pattern to what semantic versioning is all about, which is the plodding software development process of old.

What. No, that doesn't follow at all. This is the equivalent of "hate leads to suffering".

Just increment the last number on each deploy. X.Y.123456789 is perfectly acceptable. Or if that strikes you as a distasteful abuse of the "patch" value, add another layer to get X.Y.Z.12345689. Semver systems will be perfectly happy with a 4 layer option, because none of them are stupid enough to be useless when handling edge cases.

The author has actually no clue what semantic versioning is. He keeps on saying that with small, frequent and well tested changes you constantly produce "stable" builds and therefore don't need the complexity of semver, but he doesn't seem to understand that this has absolutely nothing to do with semver.

Even the smallest and most stable change can break backwards compatibility or fix a bug or add a new feature and semver's only purpose is to meaningfully express what kind of change it is. You build a 3rd party package or a library which is used by other people? You better use semver. It makes everyone's life easier and not more difficult. You build some REST API which is consumed by other applications? You better use semver. It not only helps to visually display what kind of change it was, but it also triggers an additional thought process during development and CI. For example if the major version doesn't change, then the CI system can reliably replace the existing API during the deployment process. However when the major version changed, then you might want to think about a side-by-side deployment to support backwards compatibility, at least for a certain grace period. It makes life in many ways easier.

And again, this has nothing to do with how stable a release is. Let's say I have a public facing REST API and I make a 1 line change where I decide that some field of a JSON object must be int64 because in some edge cases an int32 wasn't unique enough and would have caused a bug. Now this change is fixing the system, making it even more stable but essentially breaking existing integrations. Semver helps me to easily communicate the change to my API consumers, setting up the right expectations and helping them and myself by reducing frustration, tech support and unwanted side effects. It also helps to deploy it in a way that allows a smooth transition to the newer API.

Furthermore his suggestion of using a date is useless. What does a date tell me? Nothing... if I want to know the date I right click the files of a build and look at date + time or I look at the commit time in git or the build time in the CI tool. Having it in the version is stupid.

Ehhh... at best it argues that it's over-complicated for something that only ever has a single version running everywhere. Like a web service that you control, for which there will never be a way to request "use that old version of the code instead".[1]

Which is true. But then why even bother with YYMM.xxxx? Just use a single incrementing integer. Or none - nothing can ever go backwards, so callers are required to ignore the version in practice.

[1]: an API presenting an old external interface is something different - there's still only a single "version" of the code that's actually running.