Slashdot Mirror
The Amazing World of Software Version Numbers
Harry writes "In theory, software version numbers should be incredibly mundane. In reality, companies have long twisted them for marketing purposes, avoided ones they didn't like, and even replaced them with things other than numbers. I've prepared a tribute to them with some facts and ruminations, but there's a lot I don't know, and I'd appreciate help on the historical side of things. (Anyone know when the standard decimal point-based system came into use?)"
They go back significantly farther than that. I know SPSS was using major.minor version numbers back in the 70s (maybe even to the 60s), and I'm sure they didn't invent it.
Funny story from this, is that when SPSS was introducing version 10 there was apparently some consternation about having a 2-digit major version (not sure if it was a technical or a marketing concern, but it was a Big Deal to them). The solution? SPSSX version 1.0!
Another interesting version number case occured during the gcc/egcs split: The egcs releases had two version numbers for the same release: One starting with 1.0.0, numbering the egcs releases, and the other one, IIRC starting with 2.91.0, giving a "gcc version number" to indicate that it was still considered to belong into the gcc family. After egcs officially bacame gcc again, the first releases had the form 2.95.x before the 3.0.0 release came out (starting from which the numbering followed the normal schemes again).
As an additional twist, before it was decided to name the next release 3.0.0, the internal development code had the version 2.96.0, which also was used for a Red Hat gcc release. There never was an official gcc-2.96 release, though.
The Tao of math: The numbers you can count are not the real numbers.
Which points up (no pun intended) the semantic confusion of using "." ("period", "full stop") as a version component separator. Semantically, it's not a decimal radix point. Therefore, the second component of your hypothetical version is not 99/100, it's integer 99. Therefore, integer 100 is indeed > integer 99, and the "." shouldn't be pronounced as part of it.
That doesn't happen, of course; we all* say "point 99" or the like, which is exactly the same as if the "." were, in fact, a decimal point.
*Not strictly "all"; I usually say "dot" instead of "point", partly because of this confusion. This usage became mainstream with "dot Net" since the string "Net" makes no sense as a real number "r" such that 0 > r > 1.
Welcome to the Panopticon. Used to be a prison, now it's your home.
A.B.C.D
A: Major Release, violates backwards compatability
B: Feature Add Increment. Indicates new features from prior release
C: Bug Fix Release Increment.
D: Build Identifier usually YEARMONTHDATE
e.g.
1.1.0.080215
1.2.12.090714 (12th minor update to feature set 2 for release 1 built on July 14th 2009)
1.3.1.091224 (First minor update for feature set 3 built on Dec 24th 2009.)
Since most software tends to follow quarterly or monthly release schedules you rarely get more then 18 minor revisions if they are building weekly on a quarterly schedule or more then 4 on a monthly schedule.
-=[ Who Is John Galt? ]=-
Oh, I don't know, there's lots of cat species. I myself an breathlessly awaiting Mac OS X version Iberian Lynx, which will be one better than Asiatic Lion. Perhaps that doesn't have quite the same ring to it though. They could also do extinct species, like sabertooth, which would be a decent name.
In all honesty, I do wonder why they haven't done a Lion version yet.
Gentlemen! You can't fight in here, this is the war room!
Actually the reason the minor version number started at 16386 is that the part of the upper bits for the version number are used to indicate branch. In this case the release bit is set to 1, if this was a 'test' build then it would be set to 0. Another bit (which isn't set) is used for the corporate branch, which includes security updates that aren't as fully vetted and changes to core components requested by corporate partners. Additionally, the lower 16 bits of the build (6000) is used to indicate service pack (at least that was the plan right before release). This change to how service packs were handled was done in the last month, and yes Microsoft fudged the version number towards the end so it would be 6000 (although it was close to that at the end).
(I was the performance test engineer for Vista update services during the initial release of Vista)
That's actually not rare at all. For example Firefox went (briefly) to 0.10 after the 0.9 series. It merely depends on whether you think of the version as a decimal number with a fraction or as two (or more) numbers, separated by a dot.
The article states,
Did Windows 95 start the idea of using years instead of version numbers?
Nope -- it's a far older conceit than that. The earliest example I'm aware of is Fortran 66 ...
I believe Algol 60 predated that by a good 6 years, and Algol 58 by an additional two. While Algol 58 didn't see as wide usage, Algol 60 was, to many, the definitive version of that language.
See http://en.wikipedia.org/wiki/ALGOL
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
The article asks "has anyone ever been brave enough to sell a version 13 of anything?"
There was AutoCAD Release 13 back in the day.
The first dBase was dBase II (from Ashton-Tate) to indicate it was more stable than the non-existant dBase I (Vulcan perhaps :) ).
[John]
Shit better not happen!
No, you're entirely wrong. The version number has been chosen specifically in regard to applications which check the first number (6) only, in order to not break them (since Windows 7 remains compatible with mostly everything Vista, this is a good thing).
It still remains a major performance/stability/feature upgrade, thus why it is NT "7" theoretically.
Actually, Microsoft has said it's only for application compatibility. Apparently a bunch of applications broke when going from 5.1, 5.2 (XP) to 6.0 (Vista). Why should Microsoft "lie to applications" and complicate things when they can just do what they did when going from 2000 to XP and change the minor number, as 91degrees said, version numbers are arbitrary. For what it's worth, I'm running the Release Candidate and it is a major improvement over the pre-SP2 Vista I ran for several weeks before reverting to XP.
This was not as arbitrary as one might think. Toward the end of NS4's actual development cycle, there was an attempt to wring another major version out of that codebase, and it was called Mozilla 5. Eventually it was abandoned because the new NGLayout engine (now known as Gecko) was much better than the clunky old Mosaic-derived codebase. The NG stuff became the basis for Netscape versions 6 through 8, the Mozilla Suite, Firefox, Thunderbird, and lots of other things.
I know there are some Netscape/Mozilla folks around here who could correct/expand that story.
Slackware Linux skipped from 4.0 to 7.0, because they wanted number parity with RedHat and other popular distros.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Apple's recommendations from the classic Mac OS days (as explained in Technote OV 12 -- Version Territory, now #1132) were what I grew up with.
* First released version: 1.0
* First revision: 1.1
* First bug fix to the first revision: 1.1.1
* First major revision or rewrite: 2.0
The important part of version numbers is comparing them, and that's another place where Apple's classic metadata resource framework was ahead of its time.
Years later Apple chucked many of these recommendations with QuickTime/iTunes version inflation. But it's nice to see things have stabilized somewhat in that regard. QT7 and iTunes8 have had lots of revs.
Hire a Linux system administrator, systems engineer,
It isn't a proper version number. Many in between has been skipped, like going from 290 to 330.