Meaningful Version String that Reflects Release Date

We used to have problem to associate the release date for certain build numbers. The old version format before version 5 is like MM.NN.bbbb.x, this is the format that supported by Microsoft MSI. It is straightforward, whereby MM is major number, NN is minor number, bbbb is build number that keep on increasing. The last digit was used by IGX to denote trunk, whereby 0 is Stable, 1 is Candidate and 2 is Beta.

The trouble of this standard running number is we need to trace back the release date in order to know what changes were made and what features have been included. For version 5 and above, we have designed more meaningful version string that still compliant to MSI format: Y.Q.mmDD.x. It’s no longer get increased based on running number but based on chronological info, which will associate with the release cycle.

Y.Q.mmDD.x

Major Y

Y is referring to last digit for year of release, but currently the number is still one number behind. Of course we can keep the gap as it is, but we prefer and will soon do a skip to synchronize, and it will reach 2 digits by 2020.

Minor Q

Q is quarter number. We aimed to have four stable releases each year. It’s started by zero at the beginning of every year, set to 1 when release in the end of March, increase to 2 by end of June, and lastly the biggest possible number is 3 by end of September. So the number resets to zero by the end of the year, or in another word at the beginning of following year, when the Major Y increases.

Build mmDD

The build number will just follow mmDD, so obviously it will reset every year. Note that we can’t have the build number with prefix zero, so the build number compiled before October will have 3 digits instead of 4.

Trunk x

Three possible numbers for last digit has been associated to the development trunks, whereas 0 is Stable, 1 is Candidate, and 2 is Beta.

It’s worth mentioned that, this is a manually targeted version numbering system. Usually the release date that constitutes mmDD, and the last digit x that indicating development trunk can be accurate. However, the Major and Minor version number might slightly lagging behind. Especially the Quarter Q may even missed, when the features development couldn’t catch up with the planned release date, and get postponed.

As an additional note to development trunks that indicated by x, Beta will have most changes and Candidate will have moderate changes, and Stable trunk will have least changes. Anything tested in Beta will be promoted to Candidate, and anything stabilized in Candidate will be promoted to Stable accordingly.

Feel free to implement this version convention for your application if you find it useful. Do comment if you like or you have other version numbering system.