Anyone working on a modern software project has at one time or another descended through various levels of Dependency Hell. Sometimes these problems seem difficult to trace or solve. But why do we have these problems, and what can we do about it? And what role does SemVer play?

A released package can mean a lot of things to many people, so it’s important to get very precise here. When we talk about “A Released Package” it really means “one and only one exact and very specific unchanging set of files“.

Your project might use “TestingFramework”, and have installed “1.4.6“, but this is one specific package release. Also, 1.4.7 is another entirely different package release. The difference is small, but important: a package release can sometimes belong in a series of releases. That package is an unchanging and specific set of code. Re-tagging code doesn’t revoke the first package release, but rather just introduces a new package release with a rule violation that can fool a package management system (and sometimes break them). It’s not a “rewrite” of a release, but rather a re-assignment of a tag.

Packages

Packages by themselves are simply islands of code adrift and lost in a virtual endless space. Zip files, git repositories, commits, local folders… they are all “packages”. Even if you don’t manage them correctly, or use some popular tooling, it still exists in “package space”.