Versioning Systems
My custom date-based versioning system is somtimes used to identify releases and track their development status. Each version includes its status and release date, making it easy to determine when a version was created and compare releases chronologically.
The format is:
Year.Month.Day–Status
For example: 26.10.16–ReleaseCandidate indicates a release candidate dated 16 October 2026.
If multiple versions are released on the same day, a 24-hour timestamp is appended to distinguish them:
Year.Month.Day.Hour.Minute–Status
For example: 26.10.16.14.30–ReleaseCandidate indicates a release candidate created on 16 October 2026 at 14:30.
The reason for the inverted ordering, is to make them alphabetically sortable by chronology.
Semantic Versioning
Semantic Versioning (SemVer) is a widely used alternative that communicates the significance of changes between releases. Instead of using dates, it uses three numbers in the format MAJOR.MINOR.PATCH.
- MAJOR: Incremented when making incompatible changes that require users to adjust how they use the software.
- MINOR: Incremented when adding new functionality in a backward-compatible manner.
- PATCH: Incremented when making backward-compatible bug fixes.
For example, 2.4.1 represents the first patch release of version 2.4. A subsequent bug fix would become 2.4.2, while adding backward-compatible functionality would result in 2.5.0.
Prerelease identifiers can also be appended to indicate development stages, such as 2.5.0-alpha.1, 2.5.0-beta.1, or 2.5.0-rc.1 (release candidate).
Semantic versioning can be easier to read at a glance and is required for comaptiblity whith certain publishers like the wordpress plugin store. But i find it’s definitons a little to arbitrary and subjective in soem cases.