Code Versioning - Versioning scheme


The different scheme on the version number of a release of a module.

The argument it's just a number with versioning goes right out the window the moment that number is in a file path. Implications multiply.

After four hours of investigation it turned out that someone had made a breaking API change in a Java library, and had forgotten to bump up the version number — so when a dependent object tried to call into that library, the dispatch failed.


Content versioning

The one true way to address something — content-based shas. See Version Control - Commit Hash - Content Versioning

Common versioning scheme

common versioning scheme: major.minor[.revision[.build]]

  • The minor number is incremented when compatibility is broken.
  • The revision number is incremented for bug fixes or enhancements.

Semantic Versioning

See Semantic Versioning 2.0.0

Version format of X.Y.Z (Major.Minor.Patch).

Calendar Versioning Scheme




  • Major Releases.
    • Start of a new Development Cycle.
    • The release contains non-backward compatible changes compared with the previous major release number
    • Features Deprecation are applied
  • Minor Releases:
    • The release is 100% backward compatible within the major release.
    • New features must not introduce non backward compatible changes.
  • Bugfix Releases
    • The release contains only bug fixes
    • The release is 100% backward compatible. It's always recommended to upgrade as soon as possible since the bug fixes can contain security fixes.
  • Release Candidate Releases (a.k.a RC Releases):
    • Candidates for the Minor release.
    • Generally 1 or 2 before the Minor release in order to test it by the community
  • Snapshot Releases (continuous x.y-SNAPSHOT, or timestamped x.y-20110131.125707-122, or revision numbered x.y-SNAPSHOT.34017)
    • Snapshots builds happen every time there's a code commit
    • Snapshots are performed by a Continuous Integration tool.

Documentation / Reference

Powered by ComboStrap