Image Description
Other ways to version software
Semantic Versioning is useful, but it is not the only way to put numbers on software.
Remember the important point from our first versioning tutorial: version numbers are identifiers. They only communicate something useful if the developer and the user have some idea what the system means.
Calendar versioning
Some projects include the date in the version number. This is usually called Calendar Versioning, or CalVer.
You might see something such as 2026.8, meaning a release from August 2026, or a more detailed form containing the year, month and another release number.
This can be handy when the age of a release is more useful information than whether it contains a breaking API change.
Simple increasing versions
There is nothing wrong with a project simply using versions such as 1, 2, 3 and 4 if that is all it needs.
Not every tiny utility needs a constitutional document explaining what the third dot means.
Build numbers
A build number normally identifies a particular build of the software. Automated systems may increase it every time they produce a new build.
A user-facing version and a build number can exist together. For example, several internal builds might all belong to the eventual version 2.1 release.
Names as well as numbers
Some projects give releases names in addition to numbers. That can make releases memorable, but a name does not necessarily replace a useful machine-readable version.
Which system should you use?
Start with the problem you are trying to solve. If compatibility between libraries matters, Semantic Versioning may be very useful. If release dates matter, a calendar-based system may make more sense. If you make a small standalone program, a simple consistent scheme may be all you need.
The cleverest versioning system in the world is not very clever if nobody, including you six months later, can work out what it means.
Do you actually need something other than SemVer?
Suppose you maintain a small Windows utility by yourself. It has no public programming API. Users mainly care whether today's build is newer than the one they already have.
You can use Semantic Versioning. Nothing explodes.
But if deciding whether a settings-dialog change is "minor" or "patch" is consuming more thought than the change itself, a simpler scheme may suit the project better. A straightforward major/minor version or a date-based build number may communicate everything your users need.
Now change the scenario. You publish a library used by other programs, and changing a function signature can break those programs.
SemVer suddenly earns its keep because the version communicates compatibility.
The point is not to choose the cleverest numbering system. Choose the one that communicates the changes your users actually need to understand.
Further reading and external resources
For the full technical detail and current behaviour, continue with the official material below.
Previous: Semantic Versioning | Next: Versioning your own software