Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
4  
In some cases it could be ok, but that scheme doesn't handle well branches or patching old code. Take a look at the comments of this answer. –  MikMik Jan 19 '12 at 12:07
8  
Do you mean like in Windows 95 or MS Office 2010? –  mouviciel Jan 19 '12 at 13:10
2  
If your goal is to prevent having two versions created on the same day, this would do it. –  JeffO Jan 19 '12 at 13:49
2  
@JeffO Adding HHmmSS could also allow multiple releases per day. –  StuperUser Jan 19 '12 at 17:24
5  
Often several major versions are maintained in parallel, basically because new features tend to bring new bugs. Is 2012.01 better than 2011.11, or is it just a security patch variant of your long-term-support 2003.06 line? –  Steve314 Jan 20 '12 at 1:45

14 Answers 14

up vote 10 down vote accepted

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.

share|improve this answer
1  
We also have continuous deployment, and we use a major version + the date. It's simply the easiest way to keep track of what's going on. Quite frankly it's easier to query version control to pull out the source files for a given date than it is to constantly have to tag files and query that way. –  Chris Lively Jan 4 at 1:37

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.

share|improve this answer
1  
I'd argue that features often get pushed from one release to another and therefore any documentation given to a customer that "feature x will be in release 2" is likewise doomed to failure. –  Chris Lively Jan 4 at 1:38
    
@ChrisLively Absolutely. Speculative documentation and a language like "will be" rather than "expected to be" can be very painful. A good product owner will set the right expectations and plan realistically. –  StuperUser Jan 6 at 10:33

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.

share|improve this answer

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.

share|improve this answer

I think it works great. I use it for some internal software (yyyy.mm.dd) and for some open source software that I released.

It may not work in all cases.

share|improve this answer

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/

share|improve this answer

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.

share|improve this answer

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! :)

share|improve this answer
1  
The most recent 2.4 series Linux kernel is 2.4.31 from 01-June-2005, although you can incrementally patch it to 2.4.32-pre3 using a patch from 09-Aug-2005. The most recent stable series official kernels are currently 2.6.32.54 (2012-01-12) and 3.1.10 (2012-01-18). –  Michael Kjörling Jan 20 '12 at 8:47

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

share|improve this answer

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.

share|improve this answer
1  
And marketing helps you sell ;) –  c69 Jan 20 '12 at 0:00
    
Why should users need or "be encouraged" to upgrade, if the software fits their needs (including providing an appropriate level of security)? –  Michael Kjörling Jan 20 '12 at 8:51
3  
Because support is dropped for it, and you stop getting security updates. –  JohnL Jan 20 '12 at 9:35

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.

share|improve this answer

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.

share|improve this answer
    
Having multiple releases a day doesn't equate to having a release problem. What it might indicate is that you have a large project, where several people/groups are constantly working to release updates. These might be fixes or simply enhancements. –  Chris Lively Jan 4 at 1:41
    
Also, date based versions are no more "flat" than "2.1.3". Neither have meaning without context. For most VCS's pulling out a set of files by date is generally more reliable than pulling out by a label. For the simple reason that people sometimes forget to stamp a particular set of files with a version label while the VCS never forgets to date/time stamp the update. –  Chris Lively Jan 4 at 1:44

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.

share|improve this answer

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

share|improve this answer
2  
Just look at how Mozilla has changed its handling of version numbers recently. Major version numbers used to hang around forever, now it seems there's a new major version every few months. Why? - when they didn't bump the major version number, lot's of people didn't really believe there were any new features. –  Steve314 Jan 20 '12 at 1:57
    
Yeah Chrome have a bizarre versioning scheme as well - I think they'll hit issues in a year or two when they're releasing version 21474836478.0. (Ok, I exaggerate slightly but they'll hit the stupid-number point eventually). –  JohnL Jan 20 '12 at 9:34
    
@JohnL: I don't believe that the average Chrome user cares what major version it is in. The application automatically updates itself and "seems" stay the same even though a lot of changes have been made. –  Spoike Jan 20 '12 at 10:35
    
@Spoike: True. I care mainly because I use the Secunia PSI, which checks whether you have the latest versions of things. It's always telling me that Chrome 15.x is end-of-life or some such thing –  JohnL Jan 20 '12 at 11:03
    
Of course, the version numbers for the RSS standard are just mental. –  JohnL Jan 20 '12 at 12:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.