Relentless SemVer
SemVer, but you never have more than one API change per version bump. No compromises, no mercy. Even if that means you go from version 1.9.6 to 6.0.0 in one day because you didn't release for a while, and then to 6.2.4 the next day because you did some simple features and quick fixes.
This is how a machine with smooth release automation, good testing, and no feelings projected onto version numbers would do things. Simple, elegant, powerful - beautiful.
Every release becomes a discrete atom of functionality change - if two things change at once it's because they were so intimately connected that splitting any further would make for a broken or useless release. The structure of changelogs becomes simpler, and more trivial to parse and display in various ways. Users, developers, and automated tooling can isolate upgrade-caused breakages down to specific changes in one or more dependencies, then use the version of that release to easily communicate about exactly that change.
We should start looking at doing SemVer like that. This is the right direction. The future is fairly simple computer algorithms trying and testing software upgrades, calling in the conscious minds only when they've detected and then isolated the failure.


















