Date as software version number

Question

Software developers don't typically use date as version number, though YYYYMMDD format (or its variances) looks solid enough to use. Is there anything wrong with that scheme? Or does it apply to limited 'types' of software only (like in-house productions)?

Answer 1

This is something that you are going to have to take a look at from a couple of different angles as you need to take into account user needs as well as the needs of the software and developers.

In general, your customers aren't going to care very much about what the version number of the software is going to be as long as they know they are running something newer (i.e. Product 2012 is newer than Product 2010) and that they know it is up to date if there are patches that can be deployed (i.e. Product 2012, Update 10). As such, from a customer branding stand point I tend to prefer either a named releases (e.g. Windows XP, Windows Vista) followed by a strict sequence number of patches that may be installed by users.

That said though, writing software that checks things that are easy for the user tends to make the code under the hood much harder to write. Thus I tend to prefer the simple Major.Minor version scheme if only because you can do a simple number comparison to check to see something is up to date as in the following:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

To put this in a bit of context though, I generally don't care how big the minor number gets (i.e. 1.1024) which allows the above system to keep running successfully. Generally the revision numbers are only of interest to internal development and I actually haven't even really seen them affect things that much beyond just giving things an additional number to keep track of.

However, the above two schemes really only don't apply to environments where continuous deployment is being used (i.e. Stack Exchange) which is where I tend to prefer some sort of date followed by a revision number as appears to be used on the Stack Exchange sites. The reasoning for this being that versions are going to change too often in the continuous deployment environment and you may have multiple versions of the code going up in the same day which justifies the revision number and the current date is as good as any for breaking things out even more. In theory you could just use the revision number for everything but use of the current date allows you to keep track of major milestones internally that could make things a touch easier to discuss.

Answer 2

The problem with using a date, is that specifications are written against the counting numbers rather than a date when it's due.

"This piece of functionality is due to be in release 1. The other piece of functionality is due to be in release 2."

You can't refer to a date in specs, since the release date could get missed.

If you don't have such a formal process that needs different releases identified in advance, using dates is fine; you don't need to add another number into the mix.

Version numbers are unlikely to contain dates, since their context is linked to specs.
Build numbers are likely to contain dates, since their context is linked to when the build took place.

Answer 3

Although this approach has benefits as you described, there are certain drawbacks if you use date as a version number:

• Date based versions are flat. With v2.1.3 you can see the version number, sub-version number and sub-sub-version number. With 20110119 you can only see when it was written. You could group your date-based versions by month, but it still wouldn't tell you anything. You could have several slow months of small bug fixing and then two weeks of heavy coding resulting in a major release. Dates don't tell you that, regular version numbers do.

• If you really really need to change the version on a daily basis and possibly release number it can indicate that you don't have a proper release process, but instead everyone wildly changes stuff and promotes it to production servers whenever they want. If so, you have a problem with the process, and using different version number schema isn't going to solve it.

Answer 4

Versions are often used to convey information about how different a particular version of the software is from the previous one. So for example, if you upgrade from 1.0 to 2.0 of Acme, that's a major upgrade, in theory carrying major changes.

An upgrade from 1.0 to 1.1, on the other hand, is a minor upgrade and in theory carries minor, incremental changes and bug fixes.

This would be difficult to represent in a date format, though you could use a mixture. For example, v1.0.YYYY.MMDD

Answer 5

Without repeating good ideas from other answers, I have a problem in mind which wasn't addressed yet.

If you happen to do a fork, between an older version for backward compatibility, and a new version for an incompatible modernisation, you can't distinguish them via version numbers.

For example the Linux kernel was forked around the year 2000 into the old 2.4.x branch, which is probably still supported today and counts as 2.4.199, while the new version has been 2.6 for many, many years, and is 2.6.32 for older systems, but 3.2 for the newest kernels.

If you have documentation about your releases, you will double the information and tell the people, that version 20120109 arrived in 2012 at 01/09. Mh. But what, if there is a last-moment bug detection, and a release is delayed for a week, but the documentation, where the name is mentioned, is already ready, maybe printed, press information is out and so on. Now you have a discrepancy which is problematic, if version 20120109 arrived at 2012/01/13.

In SQL, the question whether IDs should carry semantic information has often been discussed, and the result is always: avoid it like hell! You're creating an unnecessary dependency. It can't be of benefit.

Ubuntu with its 04/10 scheme had its problem in 2006, when version 6.04 was delayed and became 6.06 . In year 3000 there will soon be the next problem! :)

Answer 6

There are many software packages that do indeed use the date as a version. Ubuntu comes to mind, where their version is YY.MM. And the build numbers for Microsoft Office products are also an encoding of the build date. Jeff Atwood wrote an Coding Horror blog post about version numbering, including this recommendation:

Whenever possible, use simple dates instead of version numbers, particularly in the public names of products. And if you absolutely, positively must use version numbers internally, make them dates anyway: be sure to encode the date of the build somewhere in your version number.

In my opinion, it doesn't matter as long as you are consistant and are able to go from a build version number (whatever it is) and recall all artifacts that went into that build from your version control system. Users don't typically care about version information at all, but rather the functionality provided by the system. Versioning information is only of real value to the developers.

Answer 7

Use semantic versioning - that way, you get some idea of the sort of changes being made between versions without having to inspect the code itself: http://semver.org/

Answer 8

Problem with using Dates as Version Numbers

The answers here are good, but I didn't see anyone address this concern with using dates: The user cannot determine how often modifications have been made.

What I am trying to say is that I can tell that Windows 3.1 and Windows 7 are far apart... and perhaps are incompatible. Windows 95 and Windows 2000 tells me nothing more than the year in which the product was introduced.

For example, with Python, I know that version 2.7.2 has evolved from 2.4.6. If I look further, I see that version 2.4.6 was released on December 19, 2008; and that version 2.7.2 was released on June 11, 2011. From this, I can form an opinion about the stability (i.e., frequency of release) of a product.

If, instead, Python had used release dates, I cannot know how these products might be connected. Further confusion would result, because Python 3.1.4 was also released on June 11, 2011 (the same as Python 2.7.2).

In short, I don't think that, by itself, date-versioning is valuable.

Answer 9

Using Version numbers is a way to show how BIG the change is

For example 2.4.3 may mean version 2 is the major change to the entire system. .4 is a minor update. and the last .3 is a small bug fix to that version. That way its easily recognisable how much has changed between each version.

Having said that I still see many people use dates or SCM revision numbers as version numbers so long as you have some way to track back to supporting release notes and documentation of what was in-scope for that release there is no real problem.

Answer 10

Some good answers here already, but I would like to point out a case where using dates makes perfect sense: small libraries or snippets of code where the code is likely to be updated frequently but in tiny bits with no single version differing drammatically to the previous one.

In other words I'm talking about situations where there's no actual "version number" but basically a sort of quasi-daily repository dump.

When I come across this kind of stuff I usually welcome the choice as it's more useful for me to know that I'm using a relatively current script/lib rather than a specific version.

Answer 11

Dates as a version number is good for marketing. If people are using "Windows NT 5.0", they might not realize it's obsolete. But if people are still using "Windows 2000", they'll instantly know it's a 12-year-old OS and be encouraged to upgrade.

However, it does make it harder to distinguish between "major" and "minor" updates.

Answer 12

Let's say some customers use version two of your product, and some have upgraded to version three, and that upgrade is not a decision made lightly.

Say the last version of version two is 2.3.2, and version three is at 3.0.3. Now you find a vulnerability that absolutely needs to be fixed, so you release 2.3.3 and 3.0.4 on the same day. Can you see how the release date is totally irrelevant? You may have stopped work on version two in 2013 and only released some essential bug fixes since then. The date is irrelevant compared to the version number.

Answer 13

I don't like this idea, for reasons already described by others. Just use the major.minor.bugfix scheme - there's a reason why most people do it this way.

But whatever you do: pick one version-naming scheme, and stick to it. Don't do it like Windows, where they change the scheme with every release. And don't do it like Android, where each release has an API version number (8), a version number that's intended for marketing (2.2) and a stupid name (Froyo).

Answer 14

Date As a Version

If your product is not sold then just using the date is fine and probably useful. If you sell it and upgrades to customers they want to buy a model with a specific set of features. It is much easier to sell them on an upgrade if this model has a clear name, it does not really matter what it is but for example no one really buys the 2012 Jan 20th Ford Car they want the Kia Model whatever. The same is true of software. Giving a hard model name and version means it has features different from an older one. For me just a date does not do that, it says I made it then, not it might have new features.

Scheme We Use

I made no claim that our system, creates a clear brand as above. We now use a four part scheme. A version number, state, the date and a checksum.

1200_GLD_120120_F0D1

This may seam over the top but it allows for us to have several versions of the build for version 1200 that our engineers can use and we differentiate between them by date. The state tell people if it is a internal test version, customer patch build or gold release. The checksum is new, it allows an engineer or customer to verify that they actually have downloaded the correct one from our distribution.

So we might have a sequence of

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

We only normally refer to the major version numbers to customer ie "12" but a customer will get the latest gold version of 12 ie 1200_GLD_120120_F0D1 unless they need the Fix.

Answer 15

Many answers here.

I want to address a problem that was not addressed yet: ambiguity.

A version and a code state (a.k.a "commit" or "revision") should have a 1-to-1 mapping, meaning that each version should have a unique code state.

With just a date (that has single-day resolution), you can't do that. If you build, make changes, and build again in a single day, you have 2 different builds representing 2 different code states, but they share the same version.

If a user experiences a bug, and sends you the version, you still don't know what state the code was in for that build.

Even if you increase the date resolution to the second, all it does is make a version collision less likely, but it doesn't technically eliminate the possibility, because 2 people on 2 computers could technically complete their builds in the same second.