Semantic versioning
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