What’s exactly the matter with software version numbers, such as Windows 3.11 or whatever? IIRC, the first version is 1.0, and when there are new versions coming up, there are 2.0, 3.0 and so on; minor changes are signified with 1.1, 1.2 and so on. Is this right? Why not simply give a number to every new version, no matter whether major or minor changes? I don’t think there are steadily new software versions coming up all the time, so wouldn’t it be better simply to name the version after 3.0 the 4.0 instead of 3.1, especially since even “completely” new versions are usually based on the program codes of previous versions.
Does this mean Windows 3.11 was the eleventh derivate of Windows 3.0? And what’s up with version numbers like PGP 7.0.3? Are there minor changes within a derivate? Why not use 7.3 instead of 7.0.3?
There is no consistency in version numbers (one reason why Microsoft stopped using them). The general rule was the first number indicated full updates – new features, new design. The number after the decimal indicates major technical changes, while the second number indicates minor changes.
But those rules were not always followed. Microsoft Word, for instance, appeared as versions 1.0, 2.0, and then 6.0. Windows 3.0 was a general upgrade from Windows 2.0, and Windows 3.1 fixed the bugs in that. Windows 3.11 added some minor fixes.
So you can see why it is a general rule of thumb to avoid version 1. But George Tate got around that when he released the first version of dBASE. He called it Version 2.
Caveat Emptor. The bugs may not be fixed and the features may not be added. Only the version number may have been altered.
Well, that’s not entirely true. Microsoft markets it’s products with a “year” version, but, if you go to any Microsoft product’s help menu (Excel for example) and click on "About << application name >> " the first thing there should be a version number. My version of Excel 2000 is 9.0.4402.
Zev Steinhardt
There’re are two purposes for version numbers, and often there are now two sets of version numbers, one for each purpose.
One purpose is marketing. Version numbers, like it or not, have acquired “meanings” above and beyond mere indication that a version differs from a previous one. Almost no one will release a software product numbered 1.0 these days, since the “meaning” of that in most minds is “this is the first released version of this product and it’s bound to have lots of bugs that weren’t found in testing”. Quite often, that perception would be dead on. Even if they aren’t downright deceptive about it, many companies will release a 1.0 version as a “limited release” to selected customers, then quickly rev the software to a 1.0.1 or even 1.1. Other companies will avoid the issue altogether and use a higher number for the initial release, often justifying this by claiming that the product is an offshoot of an earlier product line. As a general guideline, the more prominently the version number is featured in the marketing materials, the more likely it is that it bears little relationship to the actual amount of revision the software has undergone.
Besides that, standard version numbering scheme does give customers some idea of how significant the changes from the previous version are. This is far from infallible (not to quibble with RealityChuck, but Windows 3.1 probably ought to have been called Windows 4, as it represented a huge step forward from Windows 3.0, and Windows 3.11 probably should have been at least a 4.1 release), but generally every version with the same “major” version number (the number to the left of the decimal) is built around the same code base. You’re right that even major versions typically reuse the code from previous versions, but a major release usually incorporates extensive changes to that code – fundamentally different ways of doing things, entire sections of the code rewritten completely, etc., often to the point of introducing incompatibilities with previous versions. In other words, while features (even significant features) and bug fixes may be included in a “x.1” or “x.2” release, the changes will likely be limited to the specifics of that feature or fix; you’re not likely to completely overhaul code that’s used in many places without designating it as a new major release.
In most of my software product management roles, we’ve used these basic guidelines:
Major version (number to left of decimal incremented): Substantial changes to code base and several significant new features; changes to native file format(s);
Minor version (number to right of decimal incremented): significant new features incorporated, but code base is essentially the same as previous version except as specifically required to implement features/fixes.
Sub-versions (number to right of second decimal incremented): only minor new features or bug fixes incorporated; code base substantially unchanged.
Of course, these guidelines are subject to being ignored or bent when there are perceived reasons for doing so. In some cases, a company may not want to admit to the number of changes required to fix a particular problem for fear of undermining confidence in the company or product; I’ve seen products that had been substantially rewritten passed off with only the sub-version number incremented. I’ve also seen this when company wanted to play down the number of releases they’d done recently. I’ve also seen extremely minor revisions passed off as new major versions, particularly when it’s been a long time since the last major revision and there are competitors that have newer versions available. Some companies have based whether to charge and how much to charge for an update on whether it’s a major, minor, or bug-fix version. I’ve always argued for free updates on bug-fix only releases, nominal charges for minor versions, and a more substantial charge for major releases, but sometimes this results in pressure to designate a release as a “minor” or even “major” update even when the technical differences wouldn’t warrant it.
Having the version numbers more or less accurately reflect the degree of difference from previous versions is useful not only to the customer, but also to the technical support and development teams. The problems with any given version tend to cluster in certain areas, and it’s useful when troubleshooting to be able to think about all 3.x versions, for example, as sharing certain characteristics that may not be present in 2.x or 4.x releases. Having entered the software business through the tech support department, this is especially important to me and is a big reason I’ve fought misleading designations when they’ve been proposed for products I’ve been involved with.
Which leads into the other purpose of version numbers – helping the development, testing, and tech support staff keep up with which version is which. For this purpose, some companies maintain a completely separate build number scheme that has no relation whatever to the version designators used in the marketing of the product. In most cases, however, the same scheme is used, though often it’s supplemented with an additional designator to track each build that’s done by development. At my last job, any given release to the customer would have a major, minor, and sub-version number, and internal development builds would have a “b” and a serial integer appended to the end to indicate the development build number (e.g., “2.1.4b17”). Once a given development build had passed QA and been released, the internal build number would be stripped off (so that “2.1.4b17” would become release “2.1.4”). At other times, I’ve used a system whereby the sub-version number is incremented for each development build, so that there might be significant gaps in the sub-version numbers of versions that were publicly released.
BTW:
Actually, there was a Word 4.x for Windows (and IIRC on the Mac as well), as well as a Word 5 (at least on the Mac).
Thank you very much for your extensive information about that; the thing has become much clearer to me now. But let me ask one last question: Why is my Gnotella filesharing software version 0.9.9? Is this some PR gag without any specific meaning, or does a number lower than 1 actually signify anything?
Version numbers lower than 1 generally mean the program is unfinished. Depending on the programmer, this can mean still buggy and unreliable, or merely missing Planned Feature X.
Version numbers under 1.0 are usually “Alpha” versions (to test basic features of the software) and “Beta” versions (to try to fix bugs and incorporate features to prepare for general release.
As for MS Word, there used to be 3 separate numbering series. MS-DOS numbering, Windows numbering, and Macintosh numbering. The Windows version jumped from 2 to 5 to bring it in line with the Macintosh version numbering (and why would they want to standardize with a lower version number).
Version numbers in open source / free software are notoriously useless as anything but a unique identifier for a particular version. Examples can be found of software having a complete rewrite without bumping the major number, and, conversely, major numbers sometimes increase with very minor changes. All you know is that 2.7.2.1 is different from 2.7.2.2 and you can’t necessarily infer much about what changed.
Also, there is sometimes a tendency for people to be cautious about proclaiming their software “x.0”, since that is perceived as a statement of “finishedness”. I’ve seen the first public release of projects be labeled 0.1, and subsequent releases incremented this ever-so-slowly (i.e. 0.11, 0.12…), never to reach 1.0. Linux itself was in the 0.9 realm for quite a while before being 1.0.
My favorite scheme is the one employed by the original author of LILO, the linux bootloader. There was a version number which started at 1, and it was incremented every release. It got up to version 21 and then apparently was taken over by someone else who felt it necessary to start using minor numbers.
This all changes when the software is being sold as a product, because then you’ve got marketing people involved, and the public perception of the software to worry about.