ComVer doesn't account for changes that don't change the API. For example, assume that you're using a dependency, libparser, v1.0, which uses ComVer. In versio

ComVer doesn't account for changes that don't change the API. For example, assume that you're using a dependency, libparser, v1.0, which uses ComVer. In version v1.1 they add a new function, foo() which does something that you want. However, at the time of you writing the software, the latest version was v1.2, which you use because you're a good engineer who likes to keep things up-to-date. Now think about what happens when you distribute your application to three people: - person 1 has libparser v1.0 - you program can't work, because v1.0 doesn't have foo(), so you obviously must require minor version that your program was built with - which is v1.2 - person 2 has libparser v1.2 or higher - you program works. - person 3 has libparser v1.1 - you program CAN work, since v1.1 contains foo(), but it WILL NOT work, because your application requires at least v1.2. Now, you might say, "well a developer should know that foo() was added in v1.1 and pin that as the lowest required vesion" - in which case I reply that ComVer doesn't help you a tiniest bit with this, because both API extensions and bugfixes are mashed together into a minor version, so now you have an order of magnitude more changelogs to go through. SemVer stricly separates API extensions and bugfixes so you can just browse the minor version changelogs and see which version added the feature you require.