What's In a Version Number, Anyway?

@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!

I think diversifying version naming makes sense (to everybody): it is easier to remember and it highlights major differences, say Windows 95 and Windows Vista, or Windows Mobile 2003 and Windows Mobile 6…

If naming followed the same pattern it would be so boring, and it would be like saying they are all the same…

Of course for programmers numbers are sacred whichever combination is used, be it major.minor.revision.build or time or a combination as far as they can get to the correct build, but when talking about versions even us wont’ start calling our programs in a series of numbers!

i am both a user of apps and a developer of sorts i love to know the version number its much easer for me to follow than XP, Vista (yes i know which is proceededs which) but i would rather call it Windows 5.1 an Windows 6,

in my apps i follow a basic major.minor.update.release-date
if its an nightly build that release-date portion stays in final releases its dropped, and just added some where either in the title or on the about page

and i only start calling my projects Foo 2009 or whatver after version 12 or 13

i would always rather get the highest app version because assumably its the most mature

i would rather obtain FooProject 18 rather than FooProject 1

my brother how is not a developer and is just a user seems to care just bit about version numbers he plays World of warcraft and is always comparing between computers and with his friends about what version of the game they are playing like

do you have the 3.0.7 patch yet or are you still at 2.4.1
i think using just dates is just confusing

version numbers indcate how far along in the development procces the app is 0.x is not as mature as 1.x and 1.x is not as mature as 2.x etc. (assuming they follow the major.minor scheme)

i Say Let the Marketing team have there version number and we in development will have ours

I personally prefer version numbers. The fact that I can always tell easily whether a version is newer, and how important it is, just by seeing a version number has always been very important to me.

Hey… um yeah how do they actually determine version numbers? i really need an answer for I.T plz help!

Haven’t any of you created an installer?

You need file version numbers to properly determine which files get updated- and remember, the fourth position is ignored. (at least in Windos installer)

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

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.

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.

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.

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.

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

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

Personally, I use y.W.N … for the public version, and y.W.N..<build (if necessary)> internally. y.W.N is kind of useful, as it gives a date which looks a bit like a ‘normal’ version number… Today would be 10.8.4. I also like that the public version number can be easily converted to an integer, which compares easily: 10084 is higher than 9517.

I find that version numbers are confusing for products you don’t know, and seriously, for a customer, why bother? The only version they care about is the one they use… not even the next / newer / better one… which is one of the reasons we (I code web apps) are still making stuff work with IE6.

sorry, the internal number is y.W.N.[rev].[build (if necessary)] – forgot about tag stripping

If you have Windows 7, type in the “ver” command and you will see that it is not version number 7.

A simple date is the most direct way to communicate this to the user.

Version numbers are more effective, and that’s why you never hear in conversation:

“So, do you have Windows September 12, 2008 yet?”

“No, but do you have Internet Explorer October 9, 2004 yet?”

Also, is it not easier to communicate:

“You have version 3.18”

vs.

“You have the build of the program from September 28, 2010”?

The only place where dates have relevance are for people using cutting edge (i.e SVN trunks) or the developers themselves.

Looks like you misplaced where the “Revision” number and “Build” number are expected in a MS-defined version number based on that link you have. You listed:
    MAJOR.MINOR.REVISION.BUILD (which I personally like and makes the most sense to me)
However, that link you provided to MS actually lists the format as:
    MAJOR.MINOR.BUILD.REVISION.
Therefore, for anyone using the .NET System.Version class’s properties to specifically check/get the BUILD or REVISION number should be careful because it may not be what you expect… I really wish MS would do a better job explaining why they would put the BUILD before the REVISION and I wish they would provide a couple example scenarios showing when they suggest incrementing the REVISION vs. the BUILD vs. both.
I do see MS’s “Compatibility Levels” section (https://msdn.microsoft.com/en-us/library/ms973869.aspx) talks about “A new revision part indicates a QFE (Quick Fix Engineering) release…”. Then gives an example where a bug was found in vr. 1.6.5.12 and then you should make a bug fix and versioning it 1.6.5.13 (i.e. increment what they call the REVISION and keep their BUILD value the same); however, what if that bug fix requires multiple builds to fix it - should that REVISION # be incremented for each internal build required to fix that originally found bug? If so, then basically your “Main Branch”-built file versions will always be MAJOR.MINOR.BUILD.0 (where BUILD is always incremented for every official build that is a potential candidate for release off your main branch - i.e. testers officially test against); however, your “Hotfix Branch”-built file versions will always be MAJOR.MINOR.BuildFoundErrorIn.REVISION (where “BuildFoundErrorIn” does not change for that specific hotfix branch, but the “REVISION” # does change/increment with each build that your testers are testing for this bug fix). So if you had to do 12 builds as part of the bug found in vr. 1.6.5.0, then the officially released version of the file that contains the bug fix would be 1.6.5.12? Then if the another bug is found with that 1.6.5.12 bug fix released version (i.e. you didn’t actually fix the bug completely or the “fix” introduced a new bug), I assume you could reuse that same branch and just continue where it left off and start incrementing the REVISION # again starting at 13 this time. My concern here is that I thought that the Windows Installer process only looks at the 1st 3 segments to determine if a file is >= existing vr. Therefore, if 1.6.5.0 is on the machine and 1.6.5.12 is attempting to be installed, the Windows Installer will think the versions are the same ('cuz both are 1.6.5) and will not lay down the new version? I don’t know, my brain hurts.
So I think the main difference between using a MAJOR.MINOR.REVISION.BUILD version vs. a MAJOR.MINOR.REVISION.BUILD version format is more about preference and it is more important to know how the Windows Installer will look at your files when it tries to install/re-install/repair an installed version of you software - which I am also still confused about… https://msdn.microsoft.com/en-us/library/aa371221(v=vs.85).aspx, msdn.microsoft.com/en-us/library/windows/desktop/aa367575(v=vs.85).aspx, msdn.microsoft.com/en-us/library/aa368599(v=vs.85).aspx, and msdn.microsoft.com/en-us/library/aa367835(v=vs.85).aspx all talk about this saying that the version # is compared, but do not give any useful examples down to the BUILD and REVISION number levels.