I remember when Microsoft announced that Windows 4.0 would be known as Windows 95. At the time, it seemed like a radical, unnecessary change -- naming software with years instead of version numbers? Inconceivable! How will users of Windows 3.1 possibly know what software version they should upgrade to?
Yes but…
We use major version number changes when the file formats change in a non-backwards compatible way. So a user can know that: any 2.x version will open any 2.y file; any 3.z version can open 2.x and 2.y files; but that 3.z files cannot be opened by 2.x or 2.y.
This is useful information, no?
“Higher = Better”? Not always. Many times not. Let’s not even go there.
Perhaps we need a new system: “1-A” means “Acceptable number of bugs”.
“1-F” means “Fewer bugs”
“1-R” meand “Really good version, haven’t found a bug in a long time”.
Excellent suggestion. I’ve always found version numbers cumbersome and holding too much information than they really need to. I’ll definately switch to using dates in my next project …
Vista wasn’t called Windows 2005.
Of course not… it’s version 6.0.6000!
Where this becomes problematic is for software that has significant releases multiple times per year. Even then, I’d prefer “Firefox 2007 (October)” over “Firefox 2.0.5” because it conveys more information, and it’s easier to understand.
I like .NET version numbers (Major version).(Minor version).(Revision number).(Build number). The only problem is that my co-workers want the publicly released version to “have lots of zeroes”. So they would want the release candidate’s version number to be 1.0.0.0, not 1.0.0.232 (some build numbers). We never did come to a good compromise…
The Windows Mobile team can’t decide. We’ve had Palm-Size PC version 1.2, Pocket PC 2000, Pocket PC 2002, Windows Mobile 2003 for Pocket PC, Windows Mobile 2003 SE for Pocket PC, Windows Mobile 5.0 for Pocket PC, and now Windows Mobile 6.
Those versions run, respectively, on Windows CE 2.11, 3.0, 3.0, 4.20, 4.21, 5.01 and 5.02. To confuse matters further, Windows Embedded CE 6.0 (CE gained a ‘.NET’ in 4.x and lost it again for 5.0, but has now gained an ‘Embedded’) was released several months before Windows Mobile 6, but WM6 runs on CE 5.02 (which doesn’t exist outside Microsoft).
Also, Windows Mobile has sneakily added features - most significantly the Messaging Security and Feature Pack, aka Push Email - in what are known as Adaptation Kit Updates (AKUs). IIRC Windows Mobile 5.0 is now at AKU 3.5 or so.
I think that version numbers should indicate the revision and the progressive number of the build.
Here we have an automated build that runs as soon as somebody checks in the new code: this means that we should also indicate the hour and the minutes in the version number.
In Windows, the date and other info (like the the revision of the repository) can be indicated in special tags in the version’s resource.
Using dates as a version number is possible.
Unfortunatly the numbers are stil limited to 16 bit.
Yes, stil only 16 bit
20070216 or even 070216 are not possible as build numbers
Microsoft Office 2003 is a far more meaningful name than Microsoft Office 11.
If you think so, then you probably don’t really interact with non-technical users.
I have seen many people afraid of compatibility problems, because:
So, although the version number does not mean much, it gives some logic in the marketing madness.
In terms of assembly versions etc then a date doesn’t give me enough granularity - especially when I’m doing Continuous Integration. I’d end up with version numbers like 2.0.0.200702161024 - which doesn’t really work due to technical limitations of the length of the build qualifier on some platforms – so you end up using an incrementing number and labelling your source repository with this number as you do the build. Recently, we’ve started using changeset numbers from our TFS repository as the build part of the version number (i.e. 2.0.0.50118). That allows us internally to very easily tie an individual build up to the exact codebase that went into that build - that is the point of including the build section in your assembly versioning after all. I am a little uncomfortable about “leaking” internal process data out to our customers - after all why do they care what the latest changeset is for our instance of TFS - however it is just an integer that always goes up so the end-user shouldn’t ever care about that number unless we ask them for it. Because we ship “preview” versions of our software to some customers, we need to keep the build number in the end user deliverable to make sure we know exactly what version of the software they are using. We obviously never mention build numbers in marketing – they are a fingerprint only.
However, the versions assigned to code units is a different thing to the marketing name of a product. Like you say, the versions of assemblies is like a dog tag - allowing you to track down problems in the event of an emergency. Assembly versions should have little to do with marketing names. However, when you do use a version number in your name than you kinda have to change some assembly versions somewhere or is gets really confusing. For example, look at the confusion around .NET 2.0, 3.0, 3.5 etc etc. Another example on Windows is Notepad. In the RTM release of Windows Vista, the ver command reports that Windows is 6.0.6000, which has version 6.0.6000.16386 of Notepad installed - but has the notepad product itself really changed enough to justify the 6.0 moniker ??
When it comes to marketing names, a friendly name for a version is great for consumer products. Windows Vista is much more memorable to a consumer than Windows 6.0.6000. I think this is where the Microsoft marketing folks are ahead of the ones from Cupertino. I know that Leopard is the code name for the next version of OS X - however when it comes out it will be 10.somethingOrOther that I’d have to check to be sure. I find it counter-intuitive that software for written for OS X 10.5 might not work on 10.2.
In the UK a vehicle registration plate has the year that the car was registered on it - hence you feel pressured to buy a new car because it is obvious how old your existing one is. The same is true for Office 2003 vs Office 2007 etc. The Windows 95 thing was a good idea, but after a while it just highlighted how long we are going between operating system releases 
It also confused consumers when they were installing Office 2003 on Windows 95 (will it work they think - do I need Windows 2003 to run Office 2003??)
With things like Firefox, Internet Explorer, iTunes - the version number is of less marketing importance - you just want the user to be using your tool, and preferably the latest version. That is because you are not competing with yourself for market share (as Windows Vista does with Windows XP) – nor do those organisation gain much in the way of revenue by pressuring consumers into upgrading to the latest version.
One of the problems we have got ourselves into as an industry is that version numbering is used as a shorthand for lots of different things. Many corporations do not purchase x.0 releases of software - preferring to wait until a .1 or .2 maintenance release has come along. Now with “Service Packs” becoming more mainstream, this has also confused the issue. I know software vendors that release their initial versions as x.1 just to get over this corporate purchasing mentality.
For developers, we assume .NET style meanings to version numbers. 2.0 will be a major architectural change from 1.0. 2.1 will have some small breaking changes from 2.0 and 2.1.1 is just a maintenance release of 2.1.0…
In developer focussed products this can lead to tension. Java 6 has recently been released, but that is actually 1.6 of the JRE (there has been no major change in architecture to justify the major point of the version number to change, but there are a whole lot more additional features in Java 1.6 than Java 1.1…) Sun has a history of this type of marketing - anyone that uses Solaris will know about that.
For many software vendors it is a paid upgrade to go from 1.X to 2.X but an upgrade from 2.0 to 2.1 is often free. Therefore, for the vendor the choice of version number to use in their name becomes a business decision not a technical one. Additionally, because not many companies have consumer impact or the marketing clout to imprint a version name (such as Vista) in peoples minds - a version convention is a handy shortcut that expresses your products maturity and your companies continued investment in the product (again, probably the reason for Java being marketed as Java 6 rather than Java 1.6)
I’m not sure where this rant is going
Basically, I think you should use assembly versions that work for your process, are as simple as possible and leak as little information about the complications of your internal development process to the outside world as possible - but still allow you the level of tracking that you need to be able to identify and fix issues.
From a marketing point of view, what you call the next version of your shrink-wrapped product is a different decision that depends on what your target audience is.
Sorry for the rant. It’s something I think about quite a bit and don’t really have any good answers to
I wanted to implement some auto-increment version numbering in my .NET application (for internal use) as well.
I read your article and changed the version number previously just obtained from the assembly from:
v1.0.0.0
to
16.02.2007 (12:14)
It really makes much more sense for the users. At times I am going to publish versions of the app several times a day, so for users it is easier to ask wether they got “today’s 12 o’clock version”. Ah, no, you’re still using “yesterday evening’s version”.
Any kind of number is better than random cute names, as used on Mac OS X. I can never remember whether panther is newer older than tiger and so on. I know they also have numbers (10.3 and so on), but in common conversation and in marketing sometimes you just hear the names.
interesting, but I am a firm believer in version numbers and love the .NET standard.
Dates are an interesting proposition but is that the build date or the date it was ‘approved’? This is often not the same day. And what about a build that starts pre 24:00 and finishes after 24:00 - Is that last nights build or this mornings because it may very well have time tags all over the place. Similarly, the developer would need to document the date the build was going top take place wouldn’t he?
As a test professional I have to (as do users) report errors against version numbers. The .NET standard allows me (as a test professional) to understand how much testing is needed. (i.e. 1.1.1.1 - previous version 1.1.1 would not need as much testing as 1.1.3 - previous version 1.1.1.13!!)
Anyway that’s my tuppence.
Dave
I thought Microsoft changed product version numbers to named products for licensing (legal) reasons. ie. new versions of the OS/Office suites are not considered upgrades under the terms of the license and M$ are not obliged to offer an “upgrade” path.
Though perhaps I’m completely wrong about this…
Most marketing people would find it acceptable to use a version number in if you are taking about a .0 release. But unfortunately that only lasts for 9 releases before it looks ridiculous.
I don’t think anyone is looking forward to Adobe Photoshop 15.0
If we gave software dog tags, what would we put on them? Trying to keep it as simple as real dog tags is a good limitation:
Notice that Microsoft started with version numbers, went to year and then to market-speak. Customers should only need a version number when talking with tech support. A year in the name is useful for the seller - who wants to be using Windows 2000 in 2001? I’ll upgrade to the latest version!
Another thing with dates though that I really haven’t seen mentioned yet:
The different date standards that are used in the US versions EU, etc.
For example, 20070102, putting whatever decimal points you want in there. Is that January 2, 2007, or February 1, 2007? This can lead to confusion as well…
Brian,
I find the best way to handle dates, especially if they’re being used as version numbers, is yyyymmdd. This makes the version numbers increase with each release, instead of decreasing once a month (eg end of January would be 20070131 so beginning of February would be 20070201. The alternative would be 20073101 becoming 20070102, apparently losing about 3000 versions.)
I don’t care what you say, Virtuosity was an awesome movie.