I would like this idea extended to versioning, where you get a simple release number and a risk number. Even for projects following simver, they all have a diff

I would like this idea extended to versioning, where you get a simple release number and a risk number. Even for projects following simver, they all have a differing idea of how big a change is and simver doesn't cover bugfixes that make breaking API changes. If a new version simply incremented the release number, and estimated the risk of issues from the previous version, it would be easier to tell if you wanted to update. Also after a project has a few releases under its belt, you can normalize the risk to other projects risk level (eg: project x always underestimates). For open source projects, it enables tooling to look at the functions touched and the functions used by your code, and add risk to the update. An example: You are 3 versions behind, updates are versions 15/42 (minor bugfix), 16/500 (new minor feature) and 17/32000(major api change). Risk of updating is 42+500+32000. If you peg the amount of risk for a automatic update to 1000, then you would only get the first two. The same thing in simver: 1.0.1 1.1.0 2.0.0 While its somewhat easy to gate simver, it doesnt lend itself to automated risk assesment as it would be much harder for a tool to tell the difference between a bug fix and new feature (too many bug trackers out there).