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.
> When you operate a business where all the developers are on the same team then it is crazy
Even if it's not a single team, it's still crazy most of the time. I've been in orgs with tens of teams, each operating anything between 1 and 15 microservices where there was never the need for SemVer.
Upgrade strategies that span across teams are not hard if there's good telemetry and good communications. Add a new endpoint with the new desired behaviour; deploy it; communicate to your users; track usage of the old endpoint, and when it comes down to zero delete it.
Adjust this process as required (e.g. send comms in advance, give deadlines, work with consumers to expedite, maybe negotiate more time to transition, etc).
This decouples producer from consumer updates, gives everybody a chance to self organise and keeps things moving.
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.