About
The different scheme on the version number of a release of a module.
Articles Related
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.
List
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
Version format of X.Y.Z (Major.Minor.Patch).
Calendar Versioning Scheme
See: http://calver.org/
Custom
Major.Minor[.Bugfix|-rc-number|-SNAPSHOT]
where:
- 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.