What's In a Version Number, Anyway?

blog
21

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.

22

Hi Jeff

I believe the standard .NET convention for version numbers is

major.minor.build.revision

which I have always thought non-intuitive.

23

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.

24

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.

25

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.

26

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.

27

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

28

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.

29

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.

30

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!

31

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

32

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/

33

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?

34

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.

35

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

36

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.

37

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!

38

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.

39

I only say: Web 2.0.

40

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