Relentless Robot SemVer or Feely Human SemVer?

[mentalisttraceur]

I've been thinking that the Right(tm) way to do SemVer looks like a version bump for every. single. change.

Basically, each "atomic change" (from the original meaning of the word "atom" - so small you can't divide it further - a change that can't be split up into smaller independently usable changes) would get its own release and version number.

But what this means in practice is that version numbers would sprint up - sometimes there might be several "major" version bumps in a single day.

For context, if I was following that idea, just the changes I have in mind to implement and release so far would get us to at least version 5.0.0:

• 2.0.0: equality based on address size instead of type,
• 3.0.0: macaddress.MAC becomes alias instead of subclass of macaddress.EUI48.
• 4.0.0: prefix-cast construction (f.e. OUI(my_mac_address))
• 5.0.0: remove special .oui attribute.

But knowing me, I would implement and release all those in a flurry of activity over the course of a day or two. I wouldn't want to inject artificial delays between them. That's for your automation and compatibility testing to deal with, if you need the delays.

Of course this is fine and good if you really embrace SemVer as a robotic usage of version numbers to communicate programmatically useful information to tooling and automation about API compatibility.

In other words, if you think about SemVer as if you're a finely oiled machine which feels nothing except eager ruthless joy at

1. downloading each dependency as soon as it's released,
2. running compatibility tests on it, recording any deprecation warnings for later use, and
3. • if everything passes, installing and releasing it, or
   • if there is a test failure, doing a binary search between that version and the latest one which worked to find which change broke your usage of the dependency,

then one release per atomic change is really nice, elegant, sensible, and very helpful.

In fact, if you're a human in a world where that tooling exists and works well, used to working on projects which take full advantage of that in their CI/CD, well then you'd probably really want projects to roll releases like that.

But if you're a human manually watching for updates of dependencies and manually checking what changed, this would lead to a worse experience. One day you check the dependency and see that you're "four major versions behind?!?" and if you're not used to this idea, it's surprising, weird, and would probably leave you feeling like your time was wasted after you make an effort to find what major thing changed in each one, when really each one was just a tiny breaking change which didn't matter to you.

It also has a slight impression management downside: like back when Google Chrome first came out and shot through major version after major version - Firefox had been sitting in the ballpark of 3. for years, because they were saving major versions for the really big stuff, then Chrome was up at version 12. in like a year - and people felt stuff like "why are there so many major versions?" and "they're just trying to pad their numbers to look on par with the major browsers".

[mentalisttraceur]

Verdict: feely human semver for now, switch to relentless semver once I or someone else writes the nice automated tooling I envision.