I just upgraded to Firefox 2.0. Yeah, well, there will probably be minor revisions of FF before FF 3.0 arrives. You now, 2.1, 2.15, 2.2, etc.
Nope, what I don’t understand are the revision numbers for the add-ons. I find it with application software as well. Don’t developers ever release a fully fledged version 1.0 anymore? Or does the “first” version have such a stigma attached to it that developers play with sub-version 1.0 numbers all too often?
The number to the left of the decimal point is major version; to the right are minor revisions, and sometimes there’s a second decimal followed by yet another number indicating bugfixes.
I’ve seen 1.0 of many a product so I’m not sure I understand your question.
Firefox was version 1 up until just now when it came out with version 2, so…
Of the set of all positive integers, the count of numbers equal to 1 is much smaller than the count of all numbers not equal to 1. And people make more fanfare over new versions of their (successful) products, than over the introduction of their unknown and untried applications.
I think he’s talking about how lots of little trivial pieces of software, especially open-source projects, release with version numbers like 0.92 instead of 1.0.
A 1.0 release means (to programmers, not marketers) that the project has met the specification and is ready for release. Of course, programmers know that specifications are not static and that there are always bugs, so they’re loathe to release anything as 1.0, lest their sterling reputation suffer.
That’s why, for a software company, you need some dweeb in a suit to say “I don’t care if it’s not perfect! Just slap a number on the box and ship it!”
But just to be a bit more informational.
If you have a (traditional) three value versioning number, like 1.2.3, then the number on the left is the version, the middle is the subversion, and the right is the build. Essentially they just indicate how much has changed, internally.
If the version changes, then most probably large rewrites of the code happened. When the subversion changes, that usually means that new functionality was added. And when the build changes, that means they patched something (i.e. fixed a bug.)
Well, the thing is that there is a fundamental flaw with the “ideal” versioning system I stated in my previous post.
The developers need the number so that they know what version of the code someone is talking about when they send in a bug, or even just to track progress as they are still developing.
So…when you start development, what version are you at before you’ve typed up any code? The code you are writing is the version 1 code. But by common understanding, version 1.0.0 is supposed to be the first release version. Which means that you have to start at version 0.0.0, and flop it to 1.0.0 only once you are done.
But then that means that in order to create a new version of your software, you would need to start the rewrite as version 2, and the release version would be version 3.
That is to say:
0, 2, 4, 6, etc. would all be non-release, development versions.
1, 3, 5, 7, etc. would be release versions.
But again common understanding necessitates that the second release version of the app be version 2.
So overall, the versioning system doesn’t work as a versioning system. At least not as one that is pretty.
In the end you’re just as well to say that any new *.0.0 indicates the start of a new version, and whatever subversion and build number it is at when it is ready for release is just where it is. This is a lot more logical. And programmers tend to be logical people.
Sage Rat, the problem with your “programmers are logical people” statement is that in my extensive experience, version numbers are usually set by marketing for large projects. Marketing people are NOT logical: I dare you to explain the version “number” scheme for something like Microsoft Windows or Office. I was once told to increment the version number of a program from 2 to 6 because 6 was what the competing program was on, and we needed to be at least as good.
For smaller projects, the OP had it right to begin with: there’s enough of a stigma to 1.0 versions that most folks don’t want to release them. Pre-1.0 version numbers carry a “we’re not done yet, please hold” connotation. Post 1.0 numbers imply that the program has already had it’s initial bugs worked out.
But also realize that version number schemes are not standardized in the industry. A x.y.z or x.y.z.a version number can mean anything the developers/marketers want it to. About the only thing you can be sure of is that increasing version numbers mean later versions – and I’ll bet I could find counter-examples even to that.
That was my point.
Version numbers less than 1 (e.g., 0.89) are beta releases that precede an officially ready-for-prime-time first release; the programmer doesn’t consider them release-worthy yet but is allowing people access to them nevertheless because you can get some work done with them.
They are often free, and often with caveats you agree to before downloading them (“Not responsible for any damage this unfinished code may wreak on your computer”).
Sometimes it does get ridiculous: the entire history of the remote-terminal Mac program “Kermit” took place in version numbers ranging between 0.8xx and 0.993, never making it to 1.0 despite being used everywhere for direct dialup connections to other computers, and going through its various iterations for years. (One wonders what remaining / missing features would have to be incorporated, or bugs fixed, in order to qualify for a 1.0 release?)
I think MacOS X Server went from 1.0 to 10.0 in order to be in step with “regular” MacOS X, which in turn was given 10.0 to indicate that it was the successor to the code-unrelated MacOS 9.x and its predecessors; in actuality, I think the versioning under the hood was more like v.16, counting up though the various incarnations of OpenStep and NeXTStep and BSD Unix that prededed it.
It’s version inflation.
If the marketing people have their way, there never is a version 1.x of anything, just like there never is a 13th floor in an office building. So, like the 14th floor is really the 13th, version 2.x is really 1.x, which means not ready for prime time.
Pretty soon, vs 2.x will have the same stigma as 1.x, and we will get first releases with 3.x numbers, and so on, ad infinitum.
I’m a technical writer for a software company, and had a debate once with my project’s configuration management guy about what version number should appear on the documentation. I thought that the first doc version a user saw should be the same as the software version – “V.0” – to prevent confusion. He, on the other hand, thought that the version number needed to increase with each internal test candidate (TC) and release candidate (RC) that the docs went through – which meant that the user of software version “V.0” would see documentation with a version number of “V.4” (or however many TCs/RCs we went through before release). In our own little way, it was like he was the developer and I was marketing. 
He had a good point about the testers et al needing to know which version of the docs was current, and our release manager didn’t think the users would care, so that’s what we started doing. It makes sense to me in an “internal tracking” way, but I still think that if I were a user and saw a software version of “V.0” with documents versioned at “V.4” I’d wonder why.
(BTW, a fix would have been to increase the software version number to also match the number of TCs/RCs, and our CM guy would have been all for that, but the customer said something like “no way in hell.”)
Version number nonsense isn’t limited to marketing bigwigs demanding pretty digits. Sometimes, it’s the result of a developer getting sick of having to explain to the ignorant why is project is ‘behind’. Slackware, which is entirely the baby of Patrick Volkerding, jumped from 4.0 to 7.0 in October 1999 because Pat was sick of being asked why he was shipping “Linux 4.0” instead of “Linux 6.0” like all the other distros at the time. (Just for the record, the current bleeding-edge Linux version is in the unstable branch of the 2.6 series. Back in October of 1999, when the version jumped, the current kernel most distros were shipping was in the 2.2 series.)
These days, Slackware goes to 11. That’s one higher, innit?