Date as software version number

versioning

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)?

Best Answer

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.

Related Topic