What's In a Version Number, Anyway?

blog
41

Adam, what version number is your emacs? :wink:

42

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

43

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!

44

News flash: arrogance isn’t helpful either.

45

Heh. I don’t use Emacs. :slight_smile:

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.

46

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.

47

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

48

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.

49

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.

50

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.

51

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?

52

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

53

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?

54

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.

55

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

Regards,
Ronny

56

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.

57

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!

58

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

59

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

60

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