Semantic versioning

From Helpful
Jump to navigation Jump to search

Semantic versioning says to read versions like

3.1.0

like

major.minor.patch


Where

  • you increase major version to signal breaking changes, such as API changes
  • you increase minor version to indicate added features, but existing parts act the same/compatibly
  • you increase patch version to indicate bugfixes and other patches


Exactly what consists of breaking changes is still up to some interpretation. Say renaming a keyword argument isn't even a functional change, but in many cases is a breaking API change in that calls by keyword will now fail.


Instead, people seem to often not update major release until it's a large feature change, that also happens to be breaking, minor for "we're working on serous things".


That said, more package managers now do intepret semver as originally intended




You can also add prerelease label and/or metadata, like

major.minor.patch-prerelease+metadata

For example

1.2.1-beta3+20190214




On sorting - see https://semver.org/#spec-item-11

  • major, minor, and patch must be split, and sorted as integers
so lexograpical sorting is incorrect.
  • things with a label come before those without
  • labels are sorted lexograpically
  • metadata is irrelevant to sorting