I don't have a preference on semver. I don't think it completely solves versioning, or whether that can be solved. I just wanted to add a point on "dangerous".

I don't have a preference on semver. I don't think it completely solves versioning, or whether that can be solved. I just wanted to add a point on "dangerous". > (From your linked article) If an important security fix happens in a version that also contains a breaking change for your app — you still need to adjust your app to get the fix, right? Automatically upgrading to the latest minor revision is also a type of security risk. Take the example of the package manager npm, where most modules (via package.json) don't mention an exact dependency. They tend to allow minor version upgrades, via semver compatibility notation (https://docs.npmjs.com/misc/semver https://docs.npmjs.com/misc/semver). This is dangerous, since at any point, a module, sub-module (or sub-sub-module..) can release a malicious minor update which has full access to the user's data. An attacker breaking into a module author's computer simply has to release a minor version upgrade to infect dependency chains en masse. This even affects servers, since not everyone uses private npm. If the version number is pinned, you can avoid the risk. But then again, users don't get the security fixes you mention above.