On date versioning
What do you do, if you have a couple of personal coding projects lying about, want to assign version numbers to them, yet you have never learned how classic version numbering systems work. Well, you either learn that system or use something simpler.
Over the years, an increasing number of people started adapting a versioning system consisting of a day, a month and a year. In layman’s terms, the date a certain commit was released/pushed. Although I’d like to use the classic versioning system as in 0.1.2 etc., I never really understood the logic behind it. This is one of the reasons why in my personal projects I currently use the versioning format dd.mm.yyyy, which for example would look like software version 1.2.2000. Should releases/commits occur on the same day, I simply append a dash/minus followed by the letter r and a number representing the release number of a specific day, e.g.
| Date versioning system (dd.mm.yyyy) | Possible representation of classic/semantic versioning |
|---|---|
| 1.1.2000 | 0.1.0 |
| 2.1.2000 | 0.2.0 |
| 3.1.2000-r1 | 0.2.1 |
| 3.1.2000-r2 | 0.2.2 |
| 3.1.2000-r3 | 0.2.3 |
I have thought about this a lot and want to present you the many variations of that system. For example, how about swapping the r letter for a c, as in (c)ommit instead of (r)elease. It is also common practice to reverse the order. I personally think this is done to have the first number increasing last, just like with the classic versioning system. This in turn is probably done in order to create the illusion of a date versioning system close to the semantic/classic versioning system. To visualise this, take a look:
| Date versioning system (yyyy.mm.dd) | Possible representation of classic/semantic versioning |
|---|---|
| 2000.1.1 | 0.0.1 |
| 2000.1.2 | 0.0.2 |
| 2000.1.3 | 0.0.3 |
| 2000.2.1 | 0.1.0 |
| 2001.1.1 | 1.0.0 |
Now please bear in mind that the above is just a mock example. I will use three actual projects as real examples here with each of those having its own implementation of the date versioning system. Dagon, HTTPSE and Sludge Life.
The video game ‘Dagon’ uses the date versioning system in the format of:
{string} yyyy.mm.dd:{build}
The string placeholder is simply the word ‘Build’ and the number following the colon mark I assume represents the actual build number. In this case, 031 or thirty-first build. This version number can be seen on the bottom of the in-game main menu. In this case a fresh install of the GOG offline installer for Windows was used.
Dagon:
Build 2021.10.27:031
The latest releases of the ‘HTTPS Everywhere’ browser extension use the format yyyy.mm.dd
HTTPS Everywhere:
2022.5.24
While the video game ‘Sludge Life’ uses a format like Vyymmdd, which then looks like the following.
Sludge Life:
- V200803
- V200519
So this is yet another approach. I have also thought about applying the Roman numbering system as a replacement for the c and r suffix notation looking like:
| Lowercase version | Uppercase version |
|---|---|
| 1.1.2000 | 1.1.2000 |
| 2.1.2000 | 2.1.2000 |
| 3.1.2000-i | 3.1.2000-I |
| 3.1.2000-ii | 3.1.2000-II |
| 3.1.2000-iii | 3.1.2000-III |
From a date format perspective, dd.mm.yyyy looks more natural. From a programming/software angle however, dd.mm.yyyy looks unnatural, simply because the first number is increasing before the others.
In comparison:
| Date versioning system (dd.mm.yyyy) | Date versioning system (yyyy.mm.dd) |
|---|---|
| 1.1.2000 | 2000.1.1 |
| 2.1.2000 | 2000.1.2 |
| 3.1.2000 | 2000.1.3 |
| 1.2.2000 | 2000.2.1 |
| 1.2.2001 | 2001.2.1 |
Then there is of course an application of the above with yet more variations. Instead of omitting zeroes you could leave them in like so:
| Date versioning system (dd.mm.yyyy) | Date versioning system (yyyy.mm.dd) |
|---|---|
| 01.01.2000 | 2000.01.01 |
| 02.01.2000 | 2000.01.02 |
| 03.01.2000 | 2000.01.03 |
| 01.02.2000 | 2000.02.01 |
| 01.02.2001 | 2001.02.01 |
Yet another method is the leaving out of the first two yy digits as in:
| Date versioning system (dd.mm.yy) | Date versioning system (yy.mm.dd) |
|---|---|
| 1.1.00 | 00.1.1 |
| 2.1.00 | 00.1.2 |
| 3.1.00 | 00.1.3 |
| 1.2.00 | 00.2.1 |
| 1.2.01 | 01.2.1 |
This makes sense only in a century/centurial context and is therefore not futureproof, because after the year 2099, the last two year digits obviously reset and there is no safe way of referring to a specific version between two centuries when applying the dd.mm.yy or yy.mm.dd notation. Let’s have a look at a fictional piece of software released on the first of January.
Mock software released on 1 January 2022 would be labeled 1.1.22 or 22.1.1. If that software by some miracle is still alive and gets a release on the very same day, in the next century, then we have the following mess: Mock software released on 1 January 2122 also labeled 1.1.22 or 22.1.1.
Effectively, this could be described as a date versioning system collision between two centuries. The only remedy in this case is either writing out the year completely or dropping this versioning system and use the classic one.
On a conclusional note, I think that the date versioning system is a quick and easy method for people who don’t have the time or motivation to learn semantic versioning. From a programmatic point of view though, people should probably adhere to semantic versioning for the sake of consistency and the fact that semantic versioning is more widely implemented. Ultimately, the decision is made by you.
Last update: 24 February 2023