Ask HN: What about Version Pinning?

Nowadays some languages/environments offer the possibility to pin the versions of dependencies. I have a colleague who is religious about the opinion that all versions of dependencies should be pinned. To me this is not obvious at all. I see potential problems with pinning versions but I also don't feel I know enough about the pros and cons. Let me list the problems that I see.

1) What about the dependencies of dependencies? If dependency A requires C and also dependency B requires C it could be that C is pinned to two different versions. Doesn't this cause problems? Do we end up with much duplication in the packed result in which two different versions of C occur? Might we in the end even end up with 10 different versions of C if it is something that is used in a lot of libraries?

2) In theory one should be able to install any version of a package as is proclaimed in the version pinning file but in practice this can fail because a particular version might be incompatible with system libraries. E.g., numpy depends on underlying C libraries in the system so we cannot have the same version on every work station. The same problem with GUI libraries.

3) There is the danger that the versions of the libraries are not updated very often and that one is programming against old versions that have problems that one would never have encountered using a newer version. Also, if one later finally updates one gets all of the incompatibilities at once instead of occasionally a small incompatibility that is relatively easy to fix.

I do see a few uses/advantages for version pinning. When one is going to create a release branch it makes lots of sense to pin the versions of everything at that point. Also, one wants to avoid the issue that the build breaks at the same time on multiple workstations because that just wastes everybody's time.