Semantic Versioning is a very simple idea on how to do principled version numbers for software. From the document:

This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that “close” isn’t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, flexible (but not too flexible) dependency specifications can finally be made.

The idea is super simple. To paraphrase the doc, its basic rules are:

  1. Your code should always have a public API, whether it’s just in docs or delineated in the code itself.
  2. Your version numbers should be X.Y.Z, where X is major version, Y is minor version, Z is patch.
  3. X = 0 means anything could change. But after that if the public API to your code changes, your major version number will increment.
  4. Your minor version number increments for all backwards-compatible functionality.
  5. Your patch increments for backwards-compatible bug fixes.

Semantic versioning is used by some package managers (e.g npm) and relied upon for accuracy in determining if things are backward-compatible. Interestingly you might realize, “What if a developer changes the version numbers wrong? Doesn’t that break everything?” Yeah, it does.