Once a piece of software (such as a utility, driver or application) is considered finished, it is released to the public. Traditionally, the software is then at version 1.0 - but many software architects, both those working for big evil corporations and those coding just for fun, choose their own ways.
This write-up aims to describe the usual way version numbers are set, and some of the terminology associated with unfinished software.
Basics of version numbering
Ordinary version numbering is used as an easily-interpreted way to let people know how far your software is in
development. These are usually appended to the end of the product name - here follows a few
examples:
Internet Explorer 5.50.4522.1800
Klient 1.00.20
Half-Life 1.1.0.4
Quake III Arena 1.27f
Microsoft Outlook 2002 (10.2627.2725)
Microsoft Windows XP beta 2
Observe how version numbers can differ in length - most of you who use IE probably never saw anything except "Internet Explorer 5.5" when you installed it. For its Office suite of products, Microsoft has been using an alternate version system which uses years, with the real version number available only for those who can be bothered to look. This makes it easier for the end user to keep track of versions. Also note how Windows XP has no version number - instead, the letter combination XP is used. Just like with Office, the real version number (5.1) can be found only by those who look for it. Also note the use of the word beta - this means the software is not actually finished yet. More about this below.
What the numbers mean
A version number
usually contains two or more of these four basic
components: Major
revision, moderate revision, minor revision and
build.
Major revision: This is usually (always?) the first number (#.x)- a new major revision of a software supposedly brings a more or less dramatic change, such as a new user interface, lots of bug fixes and added functionality. For a good example, remember how Internet Explorer changed between versions 3 and 4. A piece of software is supposedly finished (as far as testing and QA goes) when the major revision turns from zero to 1.
Moderate revision: This is usually the second number (x.#), and an increase signals a somewhat noticeable but not necessarily major change - for example, the differences between mIRC 5.8 and 5.9 are fairly unrecognizeable to most users.
Minor revision: When minor revision is included in a version number, it is usually either in a number of its own (x.x.#) or together with the moderate revision (x.x#), leading to version numbers like 5.91. A few programs use version numbers in the form of 1.2.3.4 where the 3rd and 4th digit form the minor revision. Others (like Klient) use two-digit numbers for both the minor and moderate revisions, leading to numbers like 1.23.45. Some developers also use letters to mark minor revisions, such as 1.23a and 2.34f.
Build: This is a number, usually three- or four-digit, which refers to the revision of the program's source code. Build numbers can increase on a daily basis, and the vast majority of builds are never released to the public, since the difference between, say, 5.1.2194 and 5.1.2195 is too tiny for anyone to care about. Many developers release daily or nightly builds of software they're working on, for the benefit of testers and QA (Quality Assurance) people.
How version numbers increase
Usually, version numbers increase like most
odometers - any given digit increases by one as the digit to its right "turns over" from 9 to 0. This also applies to cases where 0.99 turns to 1.00, of course. Here follows a few examples of how version numbers increase:
0.5.2 -> (minor revision increase) -> 0.5.3
1.0 -> (moderate revision increase) -> 1.1
2.9 -> (major revision increase) -> 3.0
1.0.0.9 -> (minor revision increase) -> 1.0.1.0
1.00.99 -> (moderate revision increase) -> 1.01.00
5.5 -> (major revision increase) -> 6.0
1.27g -> (minor revision increase) -> 1.27h
1.50.4582 -> (build increase) -> 1.50.4583
5.22.999 -> (build increase) -> 5.22.1000
It should be noted that version 1.n of a program isn't always followed by version 1.(n+1). It is very common for developers to skip even major revisions between public releases - for example, web browser Netscape jumped directly from version 4.5 to 6.0 as far as most people are concerned. On the other hand, most people don't know that there is such a thing as Microsoft Office 2001.
Before version 1.0 - beta testing
Before a piece of software is ready for
release - as in, published on some download
website (like
CNet's Download.com) and downloaded by thousands of would-be
users, it is very common for developers to release
public (open) or
private (closed)
beta releases. Some developers also do
alpha and
gamma releases - but all three words (letters of the
greek alphabet I might add) basically mean the same thing, namely that:
1) The software is not finished yet
2) No gurantees are given that the software will not do stupid things (such as destroy the user's hard drive)
3) If the software does a stupid thing, no-one but the user can be held responsible
4) The software is not supported, technically or otherwise
5) The software might not work on all system configurations
6) The software should be expected to have lots of bugs
7) The software will possibly cease to function after the finished version has been released
A "bug" is a flaw in a computer program, in case you didn't know. Bugs can be small or big (minor or major) and are usually fixed by the developers, who then release a new version of their software, or a patch - a small (free) piece of software which modifies another program, updating it to a newer version.
If a software "is beta" (as in, still undergoing beta testing) the word "beta" (alpha, gamma) or an abbreviation "b" (a, g) is added to the version name. It is important for developers to do this, so that unfinished test releases are not mistaken for "sharp" products. A program with a version like "1.0 beta" is NOT a finished program.
It is a fairly common practice (hey, Microsoft does it) to release more than one beta - calling the different versions "beta 1", "beta 2", etc. Others simply release "0.8 beta" followed by "0.9 beta", meaning the same thing. Some also release so-called "release candidates" - meaning the product is essentially finished, but still lacking some functionality. Release candidates are usually abbreviated "RC0", "RC1", "RC2" and so on. Here follows a few examples of beta versions:
Microsoft Windows 2000 Professional RC1
E2 Java Chatterbox Client 0.1.10.2beta
WinZip 7.1 beta
Form Follows Function alpha playtest release
As is probably very obvious by now, developers continually come up with confusing names for their products - and there really isn't anything telling them what's right and what's left either. Anyway, I hope that this little wu has been an interesting read.
Most, if not all, company and product names mentioned in this text are registered trademarks of their respective owners. Use of these names in this text unarguably qualifies as "fair use" and is therefore completely legal.