This headline is slightly dramatic*. The far worse thing with semantic versioning is that it became part of our company’s culture of collaboration. Semver sat too easily alongside multiple repositories, small uncouple components, and teams sitting in silos. There were only fifty of us!

You are beholden to use semantic versioning (and changelogs and READMEs) when there is only a one way communication channel with the consumers of your software. You can’t see their call sites so when you deprecate print_beermat() to manufacture_coaster(style=BEER), the best you can do is warn them both numerically and in writing**.

When you operate a business where all the developers are on the same team then it is crazy — unless you have thousands of SWEs — to communicate in this way. Much better to (1) rename the function (2) fix all the call sites and (3) put it up as an atomic changeset. You’d like to think I was preaching to the converted but I still see this practice happening occasionally.

* Their thesis is that authors of popular software change their APIs with reckless abandon, which semantic versioning enables.

** Or, as the original author says, just don’t delete the old print function.