Modification to the semantic versioning rules
SemVer defines rules for version naming conventions. I modify it to have padding zeros so filenames will sort in the correct alphabetical order when you get a listing of the directory. Padding zeros in front of the MINOR, PATCH and BUILD numbers.
For example, the following executables are on a production server. app uses strict SemVer, and other uses the modified (zero padded) version.
$ ls -1
app-0.11.0+1
app-0.2.0+1
other-0.02.00+0001
other-0.11.00+0001
You can see that app-0.11.0+1 appears before app-0.2.0+1, which is alphabetically correct, but not visually correct. This get compounded when you have versions 8, 9, 10, and 11. It makes it hard to see at a glance which is the newer version.
However with the padded zeros, other-0.02.00+0001 and other-0.11.00+0001 appear in the correct order.
The modified semver rules
The modified semver rules. Versions must always have MAJOR.MINOR.PATCH. For example 0.01.00. You can optionally add a build number like 0.02.00+0001. You can also optionally add a pre-release alpha/beta tag like 0.37.00-alpha.2+0095.
A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and optionally contain leading zeroes. X is the major version with NO leading zeros, Y is the minor version optionally WITH leading zeros, and Z is the patch version optionally WITH leading zeros. Each element MUST increase numerically. For instance: 1.09.0 -> 1.10.0 -> 1.11.0.
| Field | Padding rule |
|---|---|
| MAJOR | Never padded |
| MINOR | optionally padded to two digits 00 |
| PATCH | optionally padded to two digits 00 |
| Build | optionally padded to at least four digits 0000. You can pad it more, but stay consistent. |
- Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
- Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
- Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
- Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.
- Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.
- A pre-release tag may be included after the patch number and should contain an alphanumeric tag and typically a number like
-alpha.1. - The build meta data can be included by appending a plus sign
+and a 4 digit padded number like+0042or+1042.