SemVer and CalVer — 2 popular software versioning schemes


With (or revision control) becoming a standard practice of modern software development, is yet another critical practice that is aimed for packaging a group of changes together and exposing them to users in one go. The frequency of releases for a software product is usually considerably lower than that of software revisions. How frequently a software product is released depends on various factors, out of which the most important one is the adoption cadence of software product users. In order to distinguish between past and future releases, a given release should have a unique version number, and all version numbers of the same software product should follow a consistent and predefined set of rules called . There are actually quite a number of versioning schemes out there. In this post I’m going to provide an introduction to two of the most popular ones — SemVer and CalVer.


or Semantic Versioning, is likely the most widely-used versioning scheme in modern software industry. It was originally authored by and has reached its own version 2.0.0 (and yes, this version itself is a SemVer!)

SemVer parts break-down

A SemVer version number is composed of 3 parts (delimited by “.”) — MAJOR.MINOR.PATCH. According to the specification, the MAJOR number should be incremented only if there are incompatible API changes. The incremental of MINOR number is for new functionalities introduced in a compatible manner, and the bumping of PATCH number is for compatible bug fixes. There are also extensions available to the MAJOR.MINOR.PATCH format, like pre-release and build numbers. So, the version numbers listed below are all valid SemVer:

  • 1.2.3
  • 4.5.6-rc0
  • 7.8.9-alpha+001

The is a handy tool to help analyzing if a given number is a valid semantic version.


, or Calendar Versioning, is another popular versioning scheme that gained more and more adoptions during the past few years. Instead of using arbitrary numbers, CalVer chooses to use numbers that match the calendar information a given version is released, e.g. 2020–05, 2020.05, 20.05 (all indicating release time of May 2020).

Similar as SemVer, a CalVer could be comprised of a few segment of numbers and modifiers. The 1st segment usually container the year information, which could be full year (YYYY), short year (YY), or zero-padded year (0Y, relative to year 2000). The 2nd segment could be either another calendar information (e.g. month — MM/0M), or an incremental release number of the year.

CalVer parts break-down

In the above example, the 1st segment is a full year number, followed by the release number of the year (2nd segment), the build number of the release (3rd segment), and the status of the release (4th segment). You may notice this version is actually using a mixed scheme with both CalVer and SemVer characteristics included.

CalVer is usually selected by projects if they would like set steady cadence and user expectation for the release time of future versions. Ubuntu project versioning is a good example of CalVer, that not only it’s easy to tell when a given version is released, but also whether it’s a long-term support (LTS) version, simply by referring to the last digit of the version.


I hope after reading this post you get some basic ideas what software version and release are used for, and are able to recognize the 2 most popular versioning schemes in modern software projects / products. Please note the decision for versioning scheme varies. Sometimes a mixed scheme is selected to take advantage of the benefits from both worlds.



OpenSource & Automation make me excited. Release engineering @MongoDB

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Luke Chen

OpenSource & Automation make me excited. Release engineering @MongoDB