Software versioning is the practice of assigning identifiers to distinct releases. This page records the scheme used on this wiki and the alternatives it was chosen over.
Scheme used here
Four sequences, major.minor.patch.build - the form used by the release logs
on ASTAR, RTD1073, Netgem and Tiny6410, for example
NTV350_Diag_1.0.3.4.
| Field | Increment when |
|---|---|
| major | The interface changes in a way that breaks existing users. |
| minor | Features are added, but existing users are unaffected. |
| patch | Only defects are fixed. |
| build | A new build of otherwise identical source. |
Any field that increments resets every field to its right.
Other schemes
- Semantic versioning - three sequences with the same major/minor/patch
rules made explicit and machine-checkable. See semver.org.
- Date-based -
2015.04or20150401. Says when, not
what changed; useful for rolling releases.
- Year of release - marketing-facing, e.g. Windows 95. Carries no ordering
information for a maintainer.
- Degree of compatibility - some projects encode ABI compatibility in the
major number so a linker can reason about it.
Practice
- The version in the binary and the version in the tag must match. If they can
disagree, they eventually will.
- Never reuse a version number, even for a build that was never shipped.
- An unreleased tree carries the next version with a suffix, not the last
released version.