What's In a Version Number, Anyway?

blog
61

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

62

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.

63

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.

64

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.

65

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.

66

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

67

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!

68

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

69

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 :stuck_out_tongue:

70

I like roman numerals too or hash tables

71

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.

72

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

73

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!

74

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

75

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)

76

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

77

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.

78

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

79

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)

80

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