Software versioning

Notes from Semantic Versioning 2.0.0

1. major.minor.patch
2. PATCH version must be incremented if only BACKWARDS COMPATIBLE BUG FIXES are introduced
3. MINOR version must be incremented if NEW, BACKWARDS COMPATIBLE FUNCTIONALITY is introduced
   1. must be incremented if any PUBLIC API functionality is marked as deprecated
   2. may be incremented if SUBSTANTIAL NEW FUNCTIONALITY OR IMPROVEMENTS ARE INTRODUCED within the private code
      1. may include patch level changes
   3. Patch version MUST be reset to 0 when minor version is incremented
4. MAJOR version must be incremented if any BACKWARDS INCOMPATIBLE CHANGES are introduced
   1. may also include minor and patch level changes
   2. Patch and minor version MUST be reset to 0 when major version is incremented

1. pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers following patch version
   1. e.g. 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
2. build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers following the patch or pre-release version
   1. e.g. 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85
3. precedence -- build metadata doesn't figure into precedence
   1. 1.0.0-alpha
   2. 1.0.0-alpha.1
   3. 1.0.0-alpha.beta
   4. 1.0.0-beta
   5. 1.0.0-beta.2
   6. 1.0.0-beta.11
   7. 1.0.0-rc.1
   8. 1.0.0

References

• https://homes.cs.washington.edu/~mernst/advice/version-control.html#status-before-commit
• https://resources.collab.net/blogs/7-version-control-best-practices-for-developers