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?

That's great, assuming you can make your release data. It's a good thing Vista wasn't called Windows 2005.

Phil's got an interesting post on the wide variety of version numbering systems: http://haacked.com/archive/2006/09/27/Which_Version_of_Version.aspx

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.

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.

The windows versioning might not be too bad, but look at this:

3.11
NT 3.5
NT 4.0
95
98a
98b
2000 aka NT 5
XP aka NT 5.1
Vista aka NT 6

I don't even wan to get started about Java. The only large software project with reasonable version numbers I have ever seen is Ubuntu. Their system is simple: Year.Month. Simple. 6.04. 6.10.

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

http://weblogs.asp.net/fbouma/archive/2007/01/05/assemblyfileversions-2-0-0-071005-is-bad-but-2-0-0-061005-is-good.aspx

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:

1) Name of product
2) Version (or date if you prefer)
3) Compiler used (and version/date) or script language used
4) Operating system product is meant for

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.

There are "internal" and "external" version numbers in software. The "internal" version number is useful for developers. I normally include a major number, a minor number, and a build number in this "internal" version number.

For example, we may talk about completely revamping our software and call the next revision "Release 3.0" as a way of talking about our redesign. I may be on the "Release 3.0" redesign team vs. my friend who is working on the next revision, "Release 2.3". We can now talk about "Revision 3" features vs. "Revision 2" features.

The minor number is a way of aiming a particular set of features and bug fixes as a package. For example, "Release 2.3" may include the new indexing scheme, a few new reports, and revamped error handling. We decided that the remote control feature will be pushed off to "Release 2.4".

As the release gets closer to reality, we may push off more features to "Release 2.4" in order to make our deadline, or (if we are lucky) about moving a few features we were saving for "Release 2.4" into "Release 2.3". Again, this gives me a way to talk internally about what is expected out of each of our releases. Are we planning on implementing that in Release 2.3 or saving for a future release?

The build number is simply a way to talk about which build in Release 2.3 I'm on. It's helpful for talking about bugs. If we are using Subversion or Perforce, the build # becomes the changelist. Now, we can talk about that fatal bug in build #2302 in Release 2.3 (or "Release 2.3.2302".

Thus, the three part revision number is very useful to me as a way of talking to my fellow testers and developers what they're working on and what they can expect in the next release candidate.

What you are talking about are external release numbers, and that's not a technical decision, but a marketing decision. As a developer, I may call one release "Release 2.3" and another "Release 2.4", but our marketing department may refer to the packages a "FooPower 3.2" and "FooPower 4.0". Maybe instead of "FooPower 4.0", they'll call it "FooPower - The Next Generation" or "FooPower X". Or, even "FooPower 2007". It's there decision.

There are advantages and disadvantages of dates. For example, what if Windows XP was called "Windows 2002?". Microsoft would find it would emphasize the lack of Windows updates. Who wants a computer in 2006 with an OS that's four years old and probably obsolete.

In fact, I bet Microsoft switched from calling their releases Windows 95, Windows 98, Windows 2000 to Windows XP because they expected that the rewrite of Windows to Windows Vista may take longer than they planned. Microsoft could hide this marketing problem by switching from years to "XP" and "Vista" as version identifiers.

Then, there are the people who think as releases in terms of months and not years. If I released "FooPower 2007" in January, do I now have to wait until next January before I can release "FooPower 2008"?

Whether dates are a good way of doing your versioning depends upon marketing, how often you release your code, and who you are releasing it to. Geeks who use FireFox may prefer to talk about FireFox 1.x vs. FireFox 2.x, and it may be a way for FireFox to get people to update their software. Office productivity packages have a much wider audience, so using years may make a lot more sense.

I do notice that my Microsoft Word 2003 is versioned "11.6568.6568", so it appears that Microsoft also uses internal (Word 11) vs. external (Word 2003) version numbers.

Hi Jeff

I believe the standard .NET convention for version numbers is

major.minor.build.revision

which I have always thought non-intuitive.

In my personal development I have adopted a simple revision number mechanism that uses dates.

I set the revision number using the following pattern

{year}.{month}.{day}.{build}

The build scripts I use set the first three values to the date the build is run and the last value to a number that gets incremented with each build and reset with each release.

This provides the best of both worlds for me as I can see the date of the build as well as the number of builds since the last release.

You know, I find it humorous that video games utilize several different schemes all at once. Take the popular Counter-Strike series. You have several different versions still in major use:

CS 1.5 -- The last update before Valve switched to Steam-only.
CS 1.6 -- It's probably well beyond 1.6, but it's the Counter-Strike based on 1.5 that you play in Steam.
CS:S -- With the ":S" standing for ":Source", it's the revision of Counter-Strike (same basic game) using the Half-Life 2 engine.

In console gaming, you'll frequently get a number appended to the end of the game, but sometimes they'll switch it up. Take the Battlefield franchise:

Battlefield 1942
Battlefield: Vietnam
Battlefield 2
Battlefield 2142

Take also the Tony Hawk Pro Skater franchise, which goes nuts at one point:

THPS
THPS2
THPS3
THPS4
Tony Hawk's Underground (THUG)
Tony Hawk's Underground 2 (THUG2)
Tony Hawk's American Wasteland (THAW)
Tony Hawk's Downhill Jam (THDJ)
Tony Hawk's Project 8 (THP8)

The funny thing is, Project 8 is meant to be Tony Hawk 8, but was released right around the same time as Downhill Jam. I, myself, saw Downhill Jam first, so I assumed THAT was THPS8. But I was wrong.

Naming conventions are completely weird, yah? Yah.

I've received 'patches' to software that contains dates, only later to be asked 'which patch for that date? there are multiple'.
Dates in version numbers as misleading and largely irrelevant to the user. Easier to remember, but the fewer digits the better in my opinion.

For 5608 to work, "Month 1" for Office 2003 and XP would have been Jan 1999

Users don't care about version numbers much. All they know is "AOL x.0 is the best AOL ever!" and assume it is. I agree that only when there is an issue does the user even need to bother with the version numbering. I don't mind the Panther/Tiger/Leopard naming scheme really. It is easy to remember, identifies a major change in the software and I think that the point is users can remember 'Tiger'. Aren't mnemonics used because they are easy to remember? Maybe they can remember 10.4.x but maybe not and who cares really? Most users are simply that, users. They aren't programmers and don't care about version numbers. They want it to work. Period. Only when it doesn't or when something bad happens is the version number important anyhow. I'm far more concerned about buggy software than I am about the esoteric numbering schemes employed by a software developer.

As stated above, I'm a big fan of version numbers for compatibility reasons. For instance, I work a lot with VRPN (.org if you care), and the major version number is a great indicator of compatibility. VRPN 6 does not talk to VRPN 7, and that won't talk to VRPN 8. VMWare will give a free upgrade to 5.5 from 5.0, but will make you pay for 6.0. Firefox 2 is significantly different from 1, and so on. And what's wrong with OS 10.4, or Oracle 11?

Model years cause feelings of obsolescence and confusion, and they tend to cause press mockery when release dates slip. (Windows 93^H^H95, anyone? Duke Nukem Forever?)

Still, both are better than the nightmare that is Windows versioning. Ask a non-techie which came first, Millennium Edition or 2000, and watch them get confused. Then try to remember in a few years how the versions NT, XP, and Vista related.

I started to put together a comment... but it quickly turned into a monster of it's own, so I posted it over at my place [http://www.codinghorror.com/blog/archives/000793.html].

The gist: I agree that version numbers don't belong in the product name, I don't agree that using a year in the product name is best either - at least not for products with shorter (less than a year) release cycles. Phil and I have discussed this a bit and I highlight some options that we're considering for Subtext.

Anyhow, great post as usual!

Son-of-a-B! I really need to start proof reading - that link was supposed to be to my post. Here: http://stevenharman.net/blog/archive/2007/02/16/Software_Versioning_vs._Naming.aspx

I liked one of the suggestions in the comments about using Year.Month.Day.Build as the version. I don't want to reinvent the wheel here when it comes to versioning, and that method fits into the existing framework - sort of.

What really bugs me is how .NET has overcomplicated the whole versioning elephant. Now there's both an "Assembly Version" and "File Version" to worry about, and it's Major.Minor.Build.Revision - huh??

Delphi used to have a wonderful little feature that would auto-increment the build number on each successive build. I've never given this topic much thought before, but all the assembly info is in the AssemblyInfo.cs which goes into source control, so I should be able to just write a pre-build action that reads the build number for this file, increments it, and writes back the YYYY.MM.DD version. Now if only there were a way to make this a default action for all new projects; if it exists in VS, I can't find it.

I figured it was worth mentioning ISO-8601, since no one has ever seemed to have heard of it.

Basically, YYYY-MM-DD

Makes sorting dates alphabetically the same as sorting them chronologically.

http://engtech.wordpress.com/2006/07/27/there-is-a-standard-format-for-date-and-its-name-is-iso-8601/

Version numbers are just fine with me. They tell me one copy is ahead of another. How do you rank XP and Vista? It may seem obvious because you are intimate with the software, but what if you weren't?

If you are using subversion, you should put the subversion rev in your version number, i.e. 5.1.0.svn version. That way you can easily know exactly what source went into any release.

Hmm - has anybody looked at this snippet from the .NET framework documentation?

"When specifying a version, you have to at least specify major. If you specify major and minor, you can specify an asterisk (*) for build. This will cause build to be equal to the number of days since January 1, 2000 local time, and for revision to be equal to the number of seconds since midnight local time, divided by 2."

So there you have it - date in the build, and if you really need to do multiple releases per day, time in the revision. I don't think many of you do multiple builds per second, so this is unique enough for developers, and to make it user-friendly you just have to do the computations to convert to a human-readable date/time. And you can still use the major/minor version number for internal development/testing purposes.

Sounds pretty convenient, I think.

If theres no version number, how are we the consumer supposed to know that 1 is better than the other? Higher # = better stuff! Duh!

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

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

<<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:
- I have Office XP, on Windows XP, I think Office 2003 only works on Windows 2003
- not buying MapPoint 2004 in 2005, because it is too old.
- asking which one is newer, Win 98 or Win Me
- asking which one is newer, XBox or XBox 360
- asking about Windows XP server

So, although the version number does not mean much, it gives some logic in the marketing madness.

I use Perforce changelist #s -- always increasing, always atomic. A little pre-build step later and I am autogenerating version info from the source control system.

Of course, the problem is that the .Net versioning thinks that each major portion is only 16-bit -- and I can see getting more than 65k changelists, so... crap.

I hijacked another field in the assemblyinfo and just put the string in place. Horrible.

Thanks Microsoft. 16-bits isn't enough for everyone.

The Apache Portable Runtime (apr) has a codified version number system that pretty much describes how a lot of OSS version numbering works.

The Linux kernel is partly an exception, but partly not; while it does ascribe extra information to version numbers, the public (kernel->user-space) API and ABI does always remain backwards-compatible between minor and patch releases.

One other thing - as OSS uses version numbers to indicate version compatibility, and places high requirements on interoperability, and doesn't need to output an incompatible x.0 release every couple of years to boost sales and give the stock a nice kick, OSS major version numbers almost never get as high as 12!

12?!? What the **** is wrong with you? Why has it taken you at least 12 attempts to get the design right to the point where you don't need to make incompatible changes anymore!?!

Linux? Version 2.
glibc? Version 2.
Gtk? Version 2.
KDE? Version 4 - but they need to change when QT, which used to be closed, did an ABI bump, and they're on version 4.
PostgreSQL? Version 8 - But the first release of the SQL verison was version 6, so it's really only on version 3.
GCC? Version 4. (OK, that one's actually getting a bit high, but it is 20 years old now)

I think that MS are moving away from version numbers in order to not advertise how long it keeps taking them to get their implementation correct. 12 major, incompatible versions, indeed!

I only say: Web 2.0.

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

Not to end users! End users want to know that they can open Word docs. Version? What's that?

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

Yes, I think that's right. Internally, version numbers can still be useful during development.

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

Good points all. If teams work in a distributed environment, tracking by date could be a little confusing, even if you use UTC date/time in the build number, since people think in terms of local date/time.

In situations like that, leaving the build as a simple incrementing value can be useful.

This thread and the comments give a lot of food for thought.

With date as version number user loose one information.
If you install some software and it is 0.9.13 you know it is beta. If you install 1.0.0 you know it is final version, and if 6.3.14 you can assume what all bugs are fixed and probably you have all functionality you ever could dream about.

Hoverer in current project we use Ubuntu date as version format.
07.02 sounds much better to user when 1.0.1 :)

Adam, what version number is your emacs? ;-)

"Users don't care about version numbers."

I did telephone tech support for a year or so, and I wish I had a nickel for every user who said something like "I'm having trouble with my Windows 97." Users don't care about *anything* that isn't directly connected to the task they're trying to accomplish. Long, complicated version numbers at least force people to look them up instead of guessing.

Microsoft doesn't have a strategy of using dates in product names; they have a strategy of isolating the marketing department's pointless, random name-changes (NT, 2000, XP, Vista) from the engineering version numbers.

If you want dates in a versioning scheme, why not just plain-old dates? Why encode them in some way that makes them harder to read?

One thing to keep in mind is the difference between "Marchitecture" and "Tarchitecture" (borrowing terms from a book whose name escapes me at the moment).

A geeky numbering scheme for versions is quite valuable for various software components suc as your individual binaries. This is part of the technical architecture.

But I agree with Jeff, when you release the software as a product, now marketing comes into play and "Windows 6.0.6" Doesn't cut it. Call it something Memorable.

If you're running Tech Support and need the actual version, ask the customer to use the Help | About box and read the underlying version numbers to get accuracy.

RubyGems proposes a *rational* version numbering policy (see <a href="http://rubygems.org/read/chapter/7)">http://rubygems.org/read/chapter/7)</a> which helps users easily determine when to upgrade and what kinds of changes are present in a release. IMHO, this system is far more useful than using years and months for the version number, like "Windows 95", because that does not provide any insight about the significance of changes present in a release.

I'm glad I live in the Open Source world, where we have a little bit more respect for users' intelligence. Dumbing everything down will not help you in the long run, Proprietary world!

News flash: arrogance isn't helpful either.

Heh. I don't use Emacs. :)

Anyway, nice try, but no cigar. The version that I would install if I wanted it would be 21.4, but this is actually version 1.21.4. After version 1.12 the authors realised that they'd never need to do an incompatible version 2, and just dropped the major version altogether. The Emacs version scheme is just {minor}.{patch}

Vim (which I do use) is on version 7, which again is getting a bit high. Although Vim never had a version 2, so it's really version 6, this is still on the high side; but then no _all_ OSS projects are that good; just a lot of them.

> We identify tons of consumer products using a simple model year designator.

In the United States, yes. Here in Europe, no. Windows 95 was our first year-based model designation, and it felt decidedly odd. I still can't think of a single consumer product I own that uses years. It's all CD620, E-500 and ML-1610. O wait, I still have an installed copy of Windows 98 somewhere, but that's really it. Cars don't even have model years here.

My experience is vastly different from the original post.

Confusion come because there are two aspects in version numbers: the engineering side, and the marketing side.

The engineering side versions number needs to be accurate and use a very coherent scheme (ie: should not change every year of so). In the opposite, marketing version schemes HAVE to change (because change generates interest).

(If you don't beleive me:
Windows 3.11 => 95A => 95B => 98 => 98SE => ME,
Windows NT4.0 => 2000 => XP => Vista
Sybase 4.2 => Sybase 10 => Sybase Adaptative Server Anywhere
Illustrator 1.0 => Illustrator 88
)

Companies with strong engineering culture can end up consitently using engineering version in marketing [Coherent numbering from Mac OS 5 => Mac OS 9, Or from NeXTstep 0.9 to OPENSTEP 4.2]

Companies generally have two different naming scheme for the internal and external aspect (But, in companies/projects with crappy marketing, the marketing takes the engineering version numbers, and present them directly to the customer. After a while, there is pressure from marketing to engineering to manipulate version numbers, at which points nobody understand what you are talking about internally or externally. Firefox is a good example of that, with a random 1.5 version poping out of nowhere, or a 2.0 that is perceived as a minor upgrade).

Sane companies have a coherent, consistent and immutable naming for eng version numbers. The most common way of internal numbering is
MAJOR.MINOR.REVISION.BUILD
MAJOR means compatibility is broken in some way by a big architectural change
MINOR means another version of a MAJOR branch, with support
REVISION is a stepping number for patch level
BUILD is an unique identifier to avoid having two identically named but different versions out there. Sometimes it is as simple as a sequential number, sometimes, it contains the build date in it.

MAJOR.MINOR define a release from which marketing numbers are derived.

Common marketing numbering scheme are:
* Directly using MAJOR.MINOR (very common in engineering driven companies, but can lead to pressure from marketing => engineering)
* Re-inventing an incremental number on top of MAJOR.MINOR, so, from the outside the product have version 1, 2, 3, 4, 5 etc.
* Mapping MAJOR.MINOR to an ordered sequence ("2000", "2003", "2005" or "95A", "95B" or "Dapper Drake", "Edgy Eft")
* Mapping MAJOR.MINOR to an arbitrary string ("XP", "Vista" or "Panther", "Tiger")

(It is somewhat interesting to see that, as the industry matured, the marketing schemes went from close to eng, to the most free form one)

[And don't get me started on individual component numbering :-)]

Whatever you do, make your version numbers sort right, at least in your internal systems. (Use Windows 1995 instead of 95)

Don't write

2007-Feb-17, or 02-17-2007, instead write

2007.02.17

It makes life a lot easier.

I think roman numerals are clearly the way to go. It's good enough for Kings and the Super Bowl!

Brian:
"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..."

Did you notice that neither the EU and US standards start with the year? Therefore, we're dealing with either Twentyember 7, 102 (US) or July 20, 102 (EU).

What about the competitive marketing aspect? Version numbers often also communicate how mature a product is.

Would you rather buy WordProcessor Pro 1.0 or WordMuncher 9.5?

Of course since there is no authority on version numbering there was a lot of cheating and starting with version 3.0 for the first release.

so have you ever used CI?
on my last project we were building a new version of the software wroughly every 2 minutes. We wanted to know which was the more recent that we could pass to QA at any one point. what easier internal way than saying version 21 or version 207 for that matter.
I agree that this is useless to a user but to internal teams incrementing a build number is incredibly simple to implement and can be read by anyone on the team.

If you use dates, how do you seperate bugfix releases from new versions? For instance, Im happing running 0.3.5; and I dont want to upgrade to the hottest/latest/wowest 0.4.0 as it will break my current setup (new configuration, etc) and I dont care about the new features as I want stability not features. Then when a new bugfix is released 0.3.6, Im going to use that one.

How is that solved when only using build dates?

Jeff said: Even then, I'd prefer "Firefox 2007 (October)" over "Firefox 2.0.5" because it conveys more information, and it's easier to understand.

It isn't conveying more information, there's important information missing from your version examples above. Here are the last four Firefox release dates and their version numbers:

December 19, 2006 (1.5.0.9)
December 19, 2006 (2.0.0.1)
November 7, 2006 (1.5.0.8)
October 24, 2006 (2.0)
September 14, 2006 (1.5.0.7)

Would you really want to release a "Firefox 2006 (October)" and then a "Firefox 2006 (November)" which wasn't an upgrade from the October version? How would the two "Firefox 2006 (December)" versions be distinguished?

Non-consumer software can stay static for months or even years, leaving a customer with say a 2002 version which is actually perfectly current and yet he is dissatified that his software is "out of date" because it is not called "2007". You could end up having to release the same thing just with an updated date to keep that sort of customer happy.
To put it another way, you are committing to keeping the product up to date with new releases every month or year, depending on how you named it.

Let marketing do whatever they want to do. Their wants and needs are quite different. At our company marketing want to use years for marketing purposes. Our products are fairly large and it takes many years before a new major release happens. I guess they found that having the year as a part of the name helps the customer remember how old a version they are running :). Sometimes they want the year to bump, even though only a service-pack has been added. Is that bad you say? Well, I can't stop them. That is their domain, their business.

Keep version-numbers for tech-reasons:
Major version - a number. Minor version - a number too (service-pack) 6.0, 6.1 6.2 etc. Major versions are planned. Minor versions are sometimes planned, and sometimes the content come up due to change requests, bugs or similar. Sometimes, while building our software though, we run into a situation were we need to push a hotfix. This is also a number. A hotfix is not a planned activity and no-one really plans for them. However - they are indeed sometimes needed, unfortunately. We now bump the software to i.e. 6.2.1. A hotfix is the smallest increment that we ever release externally, but internally during testing we still need more.

And now the date comes into play. The date is helpful for testers and developers on short-term basis during testing. It is easy to see the age of the build being tested/used. Since the preferred revision control system also has atomic check-in version-numbers, it makes sense to apply it to the version-number. because, then it is easy for a developer to work on the exact code that provoked a bug, for example.

So, to sum up:
External -> Internal
6.0.0 -> 6.0.0.2006.10.01.12334
6.1.0 -> 6.1.0.2006.12.24.12422
6.2.0 -> 6.2.0.2007.02.10.12468
6.2.1 -> 6.2.1.2007.02.19.12492

Major.Minor(Service-pack).Revision(Hotfix).Year.Month.Day.Changeset
All numbers - all sortable

Using this, we can see if the app has been through major changes, service-packs, hotfixes, dates for testing (short-term), and the changeset number (to use for fixing bugs, for instance). Also, since the changeset# is specified, there is no longer any need for labeling the source code in the revision control system (except for external releases). You may want to make sure that the version-number on the dog-tag is kept to major.minor.revision for the externally released versions (as shown above), and use the date+changeset only for the internal releases.

And, like I said: Let marketing do whatever they want to. They wanna use a fancy schmancy scheme? Sure, good for them. But the dog-tag is for tech-use, and should help the techies. And I can i.e. easily pinpoint that they lack an important hotfix, by looking at the hotfix-specifier. Sure, I could now use the changeset-number (if in the released version-number) or the date to figure this out. But that would require maintaining a separate list somewhere. I find that getting rid of that extra information to be a good trade off for the customers. It is easy for the customer to relay those three numbers upon enquiry. These three numbers doesn't say much to most users, but it isn't important for them anyway. They would only see this if they were particularly interested in it (in which case they might have the motivation to understand too) or if they need tech-support.

Always interesting reading in your column Jeff :)

Regards,
Ronny

We always had 2 build numbers. One for users, the other for testers and developers.

Users just care that We have App Version 3.8. A point release was some minor functionality, but the reality is that these things were decided by outside the dev team so we just lop that on to the start. The basic rationale was 'lots of stuff = major release, some stuff = minor release' and also, because it was a big company, a major release cost more to push to production hence everything was a minor release until they could no longer bluff 'just a trivial change'. Again, that's the politics part and we all could care less.

It's a web app, so compatability with previous versions isn't an issue.

Internally, we ran continuous integration and did daily builds for testing. We labelled builds using the same technique the .net framework internal build numbering uses.

2.0.50727.42 which is saying.
version 2.0
(200)5 July 27th
build 42

Here because we prepend the 'external' version to the build, the century part of the date is moot and dropped. It's better to have the 5 unchanging (meaning 2005) but the year could be dropped entirely. (don't drop it if you're unfortunate enough to have to develop the same version for over a year)

The reason this is useful for dev and test is timestamps on files can be changed too easily so they're not trusted, but we can inspect the version from code. We inject the build number into all the code when it gets compiled from a nAnt script, and use that same version as a tag to source control. We altered this slightly by putting .hhmm as the last bit because again, it was more meaningful to us as we would sometimes kick off a new daily build mid-day during a qa cycle and to verify they put the correct version in production. We also archived all the source, list of changes, etc into a folder structure based on this same trivially computable version.

As other posters said, knowing that someone is using last weeks build of 1.0.70217.1642 is more meaningful that build 7223 even when 7223 is computed in a similar manner. Being easy for me to trivially compute using just my own wetware (or some broken script language) is a big bonus and even non-tech people can clue in when they're ready.

For most people (and users), they stop reading after 1.0 unless specifically asked by someone so they, for the most part, don't notice.

<em>"We brought it on ourselves by letting our geeky, meaningless little construct of major and minor version numbers spill over into pop culture. It's not worth it. Let's reel it back in."</em>

Related to pop culture, it's probably not possible to reel it back in. Version numbering is now akin to progress. We see this with Web 2.0 and all the rest. This links in with the marketing comment above. Version numbers have different audiences who use them for different purposes. The goal then is to work it in a way that the multiple needs can be met without creating SID 6.7!

Adam: It's easy to say that Linux is only up to "Version 2", but you've neglected to mention that zero compatibility is maintained across the MINOR versions. Kernel version 2.6x was completely incompatible with 2.4x, which was competely incompatible with 2.2x, and so on.

In fact, the versioning system in Linux is completely arbitrary, and I think it truly epitomizes the problem that Jeff is speaking about. Each successive Windows release is a *new product* - of course it's not perfectly compatible with every single older product, but they bend over backwards (to the point of adding ridiculous cruft to the OS) in order to provide as much of it as possible.

With Linux, you never know what you're getting. What's the difference between 2.4 and 2.6? What's new, and what's just fixed? What's going to break if you update (other than "almost everything")?

This is precisely the reason that Linux won't make it outside the hobbyist world, not for a long time at least. Not only is compatibility given lowest priority, but there's not even any way to know if something is *supposed* to work because the versioning is totally meaningless and needlessly complicated (they've even added a fourth number now, ugh).

"If you install some software and it is 0.9.13 you know it is beta. If you install 1.0.0 you know it is final version..."

Yeah right! Sometimes open source projects release their final, definitive version and not only freeze, but also fossilize, the development at something like 0.6.953. Maybe they have a 1.0-phobia.

I say: let the first wide public release be 1.0. No one trusts anything.0 anyway. After that feel free to bump the first number every year, or if you expect less frequent major breaking of everything, do it then.

Aaron > OK, point to 3 bits of software which, when compiled on Linux 2.0, will fail to run without a recompile on Linux 2.6.20

I'm going to have fun actually testing that one out...

Also read the first paragraph of Greg Kroah-Hartman's kernel->device driver "Stable API Nonsense"[0] document for the actual position of the kernel developers on the kernel->user interface; it *is* stable, and there is a claim of binaries compiled for 0.9 still running on 2.6

[0] http://www.kroah.com/log/linux/stable_api_nonsense.html

Hi there:

There are A LOT of troubles with the version numbering :

a) A new concepts in decimal, the more emblematic case is MAME Projects where there are version 0.100, but 0.100 is not equal to 0.1, in fact 0.100>0.1 :-?

b) There are trouble with the subversion, how can you version-numering a two parallels projects that caming from (for example) some 3.5 version?.. may be 3.5a and 3.5b but 3.5a is minor that 3.5b?. Check sony ericssons cellphone where you can find a k510a,k510b,k510i phones, they are the same but subversioning and of course k510a is not minor that k510b.

c) There are some "tricks" behind a non-decimal number, everyone known that x.0 can be (not always) incompatible with y.0 version but also means that custumers must BUY the new products rather to wait for a (free) update. For example 3dstudio max 7.0 can upgrade to 7.1 and 7.2 but for upgrade to 8.x they must paid for the newest version even when the difference into 7.x and 8.x are too vague.

d) Microsoft can break a standard from times to times but linux keep a more stable standard for versioning, sadly the results is pain ugly for example: xemacs-el-21.4.13-8.SEL3.1.i386.rpm any people (or any non-nerd people) can understand it?.

e) The trouble in put the date into the version numbers is that custumers think that a "2006" version of some products is outdated by basis, in fact many companies launch a "post year" version, some way of "faking the date".

Version numbers by year are simply copying the auto trend which is both annoying and insulting.

Magallanes : Version numbers, although they contain a period, are *not* decimal numbers; they just happen to look like them in some cases.

Version numbers are period-separated *lists* of numbers.

1.0.1 is definitely not a decimal number as decimals can't have more than one period in them.

21.4.13-8 is definitely not a decimal, due to multiple period and a "minus" sign.

As a period-separated list of numbers, version 2.001 is the same as version 2.1, as 2 == 2 and 001 == 1. Similarly, to use your example, version 0.100 is 99 revisions after version 0.1 as 100 > 1.

In terms of packages (rpms, debs, etc...), the hyphen is generally used to indicate the separator between the upstream version number and the packager's revision. Again, to use the 21.4.13-8 example from your emacs package, that's probably the packager's (e.g. Red Hat's) 8th version of their package of emacs 21.4.13. Packager's generally release multiple packages of the same upstream version to include minor bugfixes that they don't want to wait for the next upstream version to get, or security fixes, or just improvements to how the package fits in with their distribution guidelines.

And, for the most part, people (including nerds) don't need to understand package naming systems; it's designed to be computer-readable so that your packaging tool (apt, yum, etc...) knows whether or not that package is newer than the one you currently have.

Again worth repeating to people who don't like to see the date in the version is just drop the major part of the century, use 0 padded days/months and dont put typical separators (like the -).

2005-07-27 does look too much like a date, and poor end users (myself included) worry 'gee this software is too old and must be crap' 50727 is for some reason much easier on the eye and i can still determine the date easily, but it's not yelling at me 'im a date!'

{marketing id}.{YMMDD}.{build/subversion tag}
-or-
{marketing id}.{YMMDD}.{HHMM}

Repeating previous post on ASP.NET framework version 2.0
2.0.50727.42
-> version 2.0
-> (200)5 July 27th
-> build(?) 42

As a user, I only need to see it's 2.0 and i'm happy. If I have a compatability issue I can look against the entire version and realise if the software needs something different, put that entire version into google and hope for the best.

As other people point out, because it follows the intent of the ISO standard, it also makes sorting (in filesystems) dead easy.

Once upon a time I got hauled into the bosses office and "told off" for using Julian dates as version numbers (eg: 2007.056).

Apparently, there were "too many numbers for users to understand".

Now that I am older and wiser, I have learnt to become politely ascerbic with people like this. And if they persist in behaving this way, I resign. Life's too short to work with people who can't understand numbers longer than 2 digits.

Certainly one of the things that has come out of this discussion is the difference between PUBLIC version numbers (or, if you like, "product names"), and PRIVATE version numbers.

I doubt you can get by with just one version number that serves both users and developers equally.

They should probably be, and mean, two different things.

Maybe something like this?
Product name (branch name) release.major.minor.revision YYYY-MM-DDThh:mm:ssZ build type
example:
Firefox (AMD64) 4.0.1.1234 2007-03-30T15:59:59Z Stable
Windows (Vista) 6.0.0.1234 2007-03-30T15:59:59+1:00 Internal
Vacuum cleaner (hand version) 1.0.0.5 1959-01-31T15:59:59-12:00 Beta

You’ve picked up on something that bothers me to no end – there’s simply no consistency in the programming world between different companies. Microsoft is going to do their version numbers one way, Mozilla another, Novell yet another, and every other company will do it in yet another different format. It’s very annoying, and it makes me almost wish (almost) that Microsoft would just dominate the world already so we can have a set of standards. But then, as you point out, even Microsoft can’t be bothered to stick to one format. They went from 3.1 to Windows 95 to Windows XP and Vista. Personally, I find those names completely useless. At least with the year of the release, we had an idea of when the software came out and we knew which versions were the latest. Now we’ve got to remember some very arbitrary naming system and that it goes 95, Millennium, XP, Vista, etc. The year versions are so much easier to remember and follow!

I believe there's a typo in the main text:

"In .NET, the version number convention is: (Major version).(Minor version).(Revision number).(Build number)"

Should be, according to the referenced MSDN article:

"In .NET, the version number convention is: (Major version).(Minor version).(Build number).(Revision number)"

I didn't fully appreciate using the year as a version number until I heard that the Windows after 2000 was going to be named XP. It was then I realized how useless arbitrary naming was (keep in mind, to the public, a version number is arbitrary, at most they know that 10 is newer than 9, big deal).

Using the year is a powerful marketing tool as an out-of-date version glares at you. Even the simplest of users would realize Office 2000 is really darn old now. But how old is Office XP? Hmm, I don't know, we're using Windows XP, so it must be the newest, who cares anyways.

At the very least, you could release a new version once a year, and while using the year in the name won't force people to upgrade, they'll darn well know what they're using isn't the latest. And after 2 or 3 yrs, they'll be itching to get a newer version, or at least more so if it was simply called v4.6.

The only negative aspect to this concept is that it encourages companies to release smaller increments of their software, assuming it takes a company 18, 24, 32 months to create a version normally and the move to years creates a mindset they have to release that 2009 edition within the first 2 or 3 months of the new year, or sooner!

But looking at how cars are released (sorry, I can't resist a car analogy), perhaps small releases aren't so bad and considering how software needs improvements all the time, every 12 months is more than long enough to create enough features to be deemed upgrade worthy.

And if you don't like it, just don't purchase the upgrade that year, instead buy every 2 or 3 years, nobody is hold a gun to your head on this :P

I like roman numerals too or hash tables

I'm glad someone hit the nail on the head. There is a vast difference between "Internal" and "External" version numbering.

For "External" numbers. Who cares! Lets the Marketeers do as they please. However, internal numbers are vital for the communication of what is being built.

At an atomic level the "Internal" version number is stating what version of a file should be included in a build, not just indicating that a build happened, (with some random file, unknown, in it). This fact is particularly important where different customers are paying for different upgrade paths, thus resulting in branching in the code.

Over the years I have seen what only can be called lazy development. Where every new "fix" is thrown straight into the tip of a linearly expanding codebase with no regard for what "fixes" should be in what version. This coupled with the lack of willingness on the part of most developers to understand the need and importance of internal version number cripples communications in software companies.

The principle of "Internal" version numbering is simple: "Internal" version numbering is there to show to [me] that you have built the correct thing, not just built something!!!
The schema used: - “It doesn't matter"! It's internal, so what ever works for the company.

@Jeff
>> Vista wasn't called Windows 2005.

> Of course not.. it's version 6.0.6000!

So does that mean that when Windows gets to 6.6.6000 we'll actually be in Windows Hell? After some of the issues with marketing and actual use and compatibility with software and hardware, we may already be there.

I totally agree about version numbers. Here at my job we use the maj.min.iter.svn number scheme. However, it's a government app and not meant for public consumption. As a developer, it takes a couple of minutes to remember why the current project I'm working on is 1.1.0.1856 when the major and minor should be 0.0 since the app isn't even released to production. I guess they should be like that. I don't know. I just work here. There isn't any consistency in version numbering in any of the apps around here. Some projects follow the numbering of other projects but get a different SVN number. Some go with the maj.min.svn.iter (2.25.8683.1) scheme. No sense of order.

Even Microsoft's four digit build number is mildly confusing. But it does make sense. I think build numbers are like VIN's It should ID the product AND the version. Maybe if added with a serial number, it could ID the license. Oh, wait that's already been done. I can't remember the exact software but I think Adobe at least in the past used that as part of the key. (Not a very good idea if you ask me, but that leads into another topic entirely).

Apple has been running the similar scheme as Microsoft for a while now with Mac OS X, X representing the Roman numeral 10. Then with each minor version, it gets a cat name: Mac OS X Leopard (10.5). Their updates get a single digit, the current being 10.5.3. Simple and easy to figure out. So, this means: Mac OS X Leopard Update 3.

The difference between Apple and Microsoft is that Apple openly displays its internal build numbers and makes it rather easy to discern what each component means. Where with Microsoft, all you get is a name (Windows Vista or Windows Vista Service Pack 1) which equates to some rather confusing internal numbers.

Has anyone ever looked at the IE6 (I know, it's what I have to use at work) version number? 6.0.2900.2180.xpsp_sp2_qfe.070227-2300: what? That's gotta be a form of proprietary encryption. If it's going to be confusing, don't display it to the user. A version number should be relatively simple so that when troubleshooting a problem the end user doesn't have to try and remember something like IE6's version number.

Sadly, with Windows having so many patches (darn near weekly) the simple numbering scheme can be unwieldy in itself. But, it would be simpler if there were a way to identify if a patch is missing, instead of building a list of patches installed and going to see if you have one missing. In a corporate environment, this can be a pain, but as a home user that's what Windows Update is for.

As for dumbing down all of this, if you were your grandmother, would you want or care to know all these version numbers? Probably not. That's what software update tools are for. They keep a database of software versions and do the updating for you. So a version number becomes nothing more than a key to identify updates. As Des just said, "It doesn't matter"!