Is Semantic Versioning an Anti-Pattern?

Semver is a sweet spot for libraries (tools, utilities, APIs, etc.). When a library I use isn't on board with Semver, I am often skeptical, and almost always disappointed.

For programming languages it is less clear to me that there are benefits. The same goes for living production end-services, which are the topic of the article. Said production system might (should?) be separate in version churn from any API built on top of said system, or client libraries used to interoperate with said API.

It is likely that I agree with Mr. Gillespie on the topic with respect to "always on" systems, but I do not feel strongly about that agreement? I tend to look for and focus on Semantic Versioning in its sweet spot, that is, libraries.

Having said where I agree, there was one quote of the article that stood out to me:

>it feels a little bit overly pedantic

In my experience, that's the best part, perhaps even the entire point, at least with libraries. Semver is just a method of communication, but its standardization and lack of ambiguity (relative to other systems), means that communication is all the more clear. I need a new feature and so am bumping a library to a new minor version? I'll be sure to check for other new things and for any deprecations, but won't need to worry that existing behavior was removed. Very clear.

When I am engineering a system on top of various libraries/tools, then growing and changing said system over time, I want to be able to pedantically assert what is known (as well as what is not known!) about the system's dependencies. Semver is a good tool for this job.

This seems inspired and perhaps even duplicated from what Rich Hickey recently said about Semantic Versioning (found here: https://www.youtube.com/watch?v=oyLBGkS5ICk)

I really enjoy how the package-manager for the Elm programming language automates semantic versioning by diffing your apis based on the type system.

I think a bit part of the real criticism of SEMVER stems from this inability to either automate it or use it correctly.

Hickey's discussion of the subject obviously has a lot more great points to it, and even when I don't agree, I can't help to enjoy listening :)

People write software for money, and sell it for money. Version N comes with one year of support, or until version N+1 clocks.

Enterprise software sells for even more money, and the above is even more true, usually backed up with lawyers, PR campaigns, etc.

Windows 7, 8, and 10, sound to the average person more reasonable that:

(from the article): 1612.0009, 1612.0013, 1701.0253

Thus, they are not only a rock solid pattern, they are the bloody unwritten standard and more so everybody's daily expectation.

If you deploy unknown and untested packages to production, semver is not your problem. The utter lack of testing is. When you actually push to production, your packages should be locked to what you tested.

This doesn't prevent the use of version ranges during development or testing.

Edit: To be clear, I do not work with Node. If this is standard practice for Node shops, that's terrible.

It’s tricky. On the one hand, if you could RELY on sane definitions of “breaking changes”, it can be quite simple to set up flows that evolve quickly and safely based on little more than the versions of dependencies. On the other hand, by nature software has too many combinations to test completely so you can never be sure that a change is going to be non-breaking for YOU; and ultimately you are responsible for anything that does break.

I find the right thing to do is to set up a completely parallel “beta flow” that mirrors production almost exactly, allowing you to freely dump in new changes and see what happens. Have a way to swap working beta-flow changes into production, and a way to swap it back. Then you can do anything you want in beta.