node+npm5/yarn, ruby+gemfile, rust+cargo (and maybe a few more) are the best examples for the whole workflow around packaging. Semver ranges (dependency 1.0.x)

node+npm5/yarn, ruby+gemfile, rust+cargo (and maybe a few more) are the best examples for the whole workflow around packaging. Semver ranges (dependency 1.0.x) along with version pinning (lock files that represent the currently installed versions) are the best-case scenario. One can avoid the exercise of "bumping versions" every once in a while (just upgrade all packages within supported semver ranges), get the same semver compatibility guarantees, makes sure all other team members are using same versions, and most importantly the CI process is reproduceable and can be sped up with reliable, non-broken dependency caching. The elephant in the room is Java. Despite its maturity, both mvn and gradle have poor support for ranges and pretty much no concept of lock files. Everyone is left to "bumping versions" by hand all the time, and snapshot versions are pretty much hell and lead to irreproduceable builds. Vendoring the whole tree is only an optional add-on to semver ranges. You can't vendor a whole tree and resolve all nested dependencies if everyone is using directly pinned versions! I think the article might have a fundamental misunderstanding between versioning as a library author and as a user. TL;DR - Semver ranges are great when coupled with version pinning and lock files. If not, there are some trade-offs, and as long as people are aware of the trade-offs, its still better than no ranges.