Our bespoke database here at work is listed as version 3.1.1.474; the personel database we use is version 4.0.0.8; my Internet Explorer is version 6.0.2800.1106.xpsp2.030422-1633 for goodness sake (although I guess the last two in that are OS and date/time of install)!!
My question is this: Is there any formal naming procedure for version numbers? What determines whether we go from 3.1.1 to 3.1.2 or to 3.2.0?
Or do they make it up as they go along? 
Grim
The short answer is that they make it up as they go along.
There’s a convention of Major.Minor.Build version numbering but there aren’t any laws forcing people to stick with this. Most places stick with the Major.Minor version numbers but after that it’s pretty much up for grabs and the vendors will pack in any and all information that they think will be helpful (hence that huge IE version string).
Then there are the people who skip a few versions to “catch up” to the competition. Just try finding a copy of MS Word 4.0 - at the time Word 2 was looking like a bit of a low-version amateur compared to WordPerfect 5 so they skipped right ahead to v6.
Then there’s me. I usually make sure I release something like “2.5.37r2” just to make sure the clients think they’re getting their money’s worth out of me when “0.1 beta” would often be more appropriate.
Generally speaking (but not always) a jump in the first digit (going from 3.x to 4.x) indicates a new version with lots of new features and changes to the user interface so that it looks almost like a different product.
A jump in the second digit (from 3.1 to 3.2) means that some new features have been added or changed, but the overall look and feel of the product is the same.
Changes beyond the second digit are generally bug fix releases or minor changes generally invisible to the end user.
That being said, this is by no means a universal convention, and different software makers have their own rhymes and reasons, so YMMV.
Ideally, it’s
Major Revision . Minor Revision . More minor . More minor …
A key example of this is Windows. A major revision led to Windows 3.0. Some functional enhancements created Win 3.1. Addition of Workgroup support created Windows for Workgroups 3.11. A new major revision led to Windows 4.0 (Win 95).
We use software here at the office that we have the right to modify. In that case, the revision control system assigns version numbers this way:
Vendor Major. Vendor Minor . Our Client Code. Version Number
So, if the current vendor version of a module is 8.0, and we modify it, the new version will be something like 8.0.875.1
No formal rule, really. Marketing has started to play a major role in how the numbers are assigned. For example, when JavaScript 1.0 was released, Microsoft released the competing JScript 1.0. When modifications were made to JavaScript to make it 1.1, MS released a JScript 2.0 – functionally identical to Javascript 1.1. It’s worked up to where JavaScript is at 1.5 but JScript is at 5.6 – but they’ve both gone through the exact same changes.
The short answer is: they make it up as they go along.
It depends on the vendor/developer, but generally it is major.minor.step.build, or some such. Major changes include substantial rewrites, or changes that aren’t backwards compatible. Minor changes are added features that don’t break compatibility, or just aren’t big enough to merit a major number change. Steps are bug fixes. Build is information that can be used to recreate the software from sources (i.e. tell the source control system to get me all the files that went into build 6502).
However, marketing also gets their noses into version numbers. For example, marketing might want to “keep up” with a competitor that just released version 7 of their software, so we need version 7 of ours (so they tell us that 6.3 is officially 7.0). Or perhaps they want to force users to upgrade (often support for old “major” releases extends only a few years after the next major release comes out).
Sometimes, it just means they want you to think there are major changes. Either case it’s a marketing decision.
One of the most creative version numbering schemes is the TeX typesetting program. First release version was version 3, and the next version was 3.1, then 3.14, 3.1415, and currently 3.14159. I guess the implication is that it’s not the type of program that incorporates more and more features as it evolves, but rather converge to a certain ideal (pi).
In the Open-Source world, releases that are numbered less than 1.0 are generally considered unstable beta releases, only suited to those willing to pick bugs out of the code. By releasing a 1.0, the developers are implying that the code base is stable enough that the major bugs are gone and that the next few releases can focus on features.
(This is almost, but not quite, completely unlike the closed-source world, where buying a 1.0 release is guaranteed to turn you into a raving lunatic.)
Some projects adhere to their own schemes, which (in the Open-Source world at least) are published on project pages and the like. The Linux kernel, for example, reserves release numbers ending in an odd number after the decimal point for development versions (suitable to those willing to forego stability in return for newer features and/or the chance to help develop the latest project) and those ending with an even number after the decimal point for stable versions (suitable to those who want stability at the cost of a few fewer features and/or Debian users ;)).
So, the current stable branch of the kernel is called 2.4, while the current development branch is called 2.5. When 2.5 matures, it will be made into 2.6 and 2.7 will be created to develop the next stable kernel.
The next revision will be 3.141592.
Followed by 3.1414926, and so forth.
It’s pi!
:smack:
Of course, now I wish I’d read your last sentence!
At my former employer, our system was
major.minor.bugfix.build
major is self-explanatory, a whole new piece of software
minor was a new feature addition
the bugfix value wasn’t “advertised”, it was more or less an internal value, applied to a particular major.minor version, such as when a typo in a string wasn’t noticed until major.minor.0 went out the door; quick fix became major.minor.1
build was like an odometer reading, only getting reset when major was incremented.
Some CAD software are going to version numbers like 2003.04 for the year and month they are released.
I always liked lilo’s versioning scheme: 1, 2, 3, 4, 5 etc. No matter how small a change, increment the version by one (and people could look at the “changes” file to find out how much stuff changed).
When marketing gets into the act, all bets are off. I currently work on a product that went from version 3.0 to 6.0. Reasoning - some other products in an “integrated stack” were at 4.something, 5.something, etc. Somebody decided EVERYBODY would jump to 6.0 for consistency.
I’ve seen major rewrites get called dot releases, because marketing didn’t want to “position” a new release yet, and didn’t have to do anything for a dot release. Conversely, I’ve seen intended bugfix releases bump the major number because marketing thought it had been a long time since a major release, and figured out a way to spin fixes as new features. I’ve seen meetings in which people argued for interminable lengths of time over what release numbers should be.
Build numbers often sneak in because marketing doesn’t care about them if they are hidden away in another field or at the tail end of the number, and it’s usually that number which lets you and tech support know what you REALLY have ahold of, as well as being useful for distinguishing the huge number of test versions seen internally before the thing is released.