Many package managers by default add dependencies with possibility to upgrade to a patch version, during an install. The lockfile will be updated, but the package file won’t. I think this behavior is really nasty for two reasons.

First, if you have large enough, say 10, number of libraries, you’ll lose track of what is used right now. Lockfiles are big. And even a dependency tree won’t help much, because you’ll have to compare two sources manually, with your naked eyes. You won’t have to hunt down these changes during upgrade if the package file doesn’t lie to you (versions are the same)

Second, it makes installs, builds and deploys unpredictable. Sure, patches shouldn’t break anything. But I don’t want to take chances. And I really want to ship stuff exactly like it was built, and tested. If an upgrade breaks something, you can catch it right away or hunt it down by looking at what packages were updated recently, instead of guessing what specific package or a combination of packages broke down. This also minimizes a chance that a newcomer dev will have to deal with broken stuff or a different behavior.

Some official, let alone community guides tell users to add a version which only pins library to a major version. I saw this in some Google’s SDKs. This is somewhat common in Android and iOS development, and I had numerous cases where a newer patch version was no good. The articles and guides should specify exact versions, otherwise how do I know which version to use, in case of a problem?

I want my software to be accurate, not
hit-or-miss. You want to know your exact salary, not a guess.