4 ms·
No, Semantic Versioning (SemVer) is not a silver bullet. But the concept can be an effective software stabilizer. However, utilization of unbounded versions i
by waffletower 3y ago
No, Semantic Versioning (SemVer) is not a silver bullet. But the concept can be an effective software stabilizer. However, utilization of unbounded versions in transitive dependencies (for example, `pandas>=1.5` in a python requirements.txt) can silently break this contract. Even if a transitive dependency utilizes SemVer, a consumer of such a library has to also conform. The pandas example was found in a transitive dependency in one of our production processes, and one day this April it broke our production service when pandas released its 2.0 version. We had pinned all our dependencies, but the man in the middle had not. The python ecosystem is notorious for this time consuming naiveté.
- jonhohle 3y agoOne possible issue is that compile or test time dependency resolution, especially for uncompiled languages, doesn’t distinguish betweeen explicit and transitive dependencies in most package managers/build systems. If you have a direct source dependency, imho, it should be explicit (not relied on transitively), and if not (unless a specific runtime version is necessary), transitive dependencies should not be locked or specifically annotated in a lock file. The former is overly flexible, the latter overly rigid. I also prefer an external manifest that can lock specific versions of all dependencies, but that usually requires a separate package manager from the language provided one, which introduces a whole new set of issues.