Code Versioning - Versioning scheme
Table of Contents
1 - About
The different scheme on the version number of a release of a module.
2 - Articles Related
it's just a numberwith versioning goes right out the window the moment that number is in a file path. Implications multiply. Nick Craver
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. Semantic Versioning has failed Agile - Archis Gore
3 - List
3.1 - Content versioning
The one true way to address something — content-based shas. See Version Control - Commit Hash - Content Versioning
3.2 - 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.
3.3 - Semantic Versioning
Version format of X.Y.Z (Major.Minor.Patch).
3.4 - Calendar Versioning Scheme
3.5 - Custom
- 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.