Semantic Versioning is not a magical cure-all. It's still up to the author to make the right choice about which number to bump. We have a node/gulp-driven buil

Semantic Versioning is not a magical cure-all. It's still up to the author to make the right choice about which number to bump. We have a node/gulp-driven build with, ultimately, about 500 dependencies. We don't store node_modules with the code, we run npm install with each build. This leads to periodic failures because some sub-sub-sub-dependency bumped number 3 when it should have bumped number 2, causing unwanted build-time behavior. Even if our package.json lists specific versions of top-level dependencies instead of ranges this will happen. It's aggravating. Projects exist to bundle up known-good node_modules and restore at build time to avoid this. NPM offers the concepts of shrinkwrapping and peer dependencies so you can tell consumers which specific version of each runtime dependency they have to use as well. IMO if SemVer actually worked in practice, none of this would be necessary. Some of this is an indictment of node/npm - maybe Ruby is just better - but I still think SemVer is overestimated.