The Amazing World of Software Version Numbers 321
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?)"
Re:What now? (Score:3, Insightful)
Re:What now? (Score:5, Insightful)
1.1.1 -> 1.1.2 - bugfix only, no change in what the end-user sees.
1.1.1 -> 1.2.0 - new features, perhaps a button in the UI has moved. Still fully compatible with the previous version. Documents should be stored identically, network protocols unchanged.
1.1.1 -> 2.0.0 - major release, might very well break functionality, documents may have to be converted from previous versions, UI can change drastically.
Re:What now? (Score:5, Insightful)
X.Y (B): X: major version as you've outlined. .Z, as you've also outlined: every public facing build increments Z before shipping, in order to indicate if it is a bug fix. If there is a .Z, then the build number can be hidden from the user--the only purpose it serves is for customer support to know which build the user has so bugs can be tracked appropriately.
Y: minor version as you've outlined.
(B): Build number; this is an auto-incrementing number which indicates the build. This is used for QA tracking purposes.
I can also see adding a
I don't see any reason why it needs to be any more complicated than that.
Re:Software version vs. sequels (Score:3, Insightful)
Re:Different people, different numbering schemes. (Score:3, Insightful)
I realize it's personal preference, but it irks me seeing applications with a version number less than 1. Yeah, it's fine to say "it's version 0.5 because it doesn't have all the features", but it's never going to have all the features you want or planned.
The way I see it, by definition, the first time you hit Compile, you're creating "The First Version" - version 1.0. As far as I'm concerned, it starts at 1.0, not 0.1 or 0.0.0.1 or whatever else. If it takes all the way to version 2.0 to get "all the features" you originally planned or wanted, fine, the application is now at version 2, why is that a problem? It seems like a lot of applications, especially in the open source world, insist on always having a version number less than one. A lot of times when I see that I feel that if the developer isn't confident enough to call their application "The First Version", there's no way I'm going to use it. That's probably putting more weight on version numbers than is intended, but version numbers are all about perception anyway (just ask Netscape 5).
And no, zero-based arrays are no excuse for now starting every numbering sequence with a zero. The word "first" is the ordinal form of the number one, not zero. By definition then, "The First Version" is version 1.
Re:What now? (Score:4, Insightful)
> 1.1.1 -> 2.0.0 - major release, might very well break functionality, documents may have to be converted from previous versions, UI can change drastically.
Um, you missed the most important part.
1.x -> 2.x releases are when the business needs upgrade revenue, whether there is significant, useful new functionality or not.
Re:What now? (Score:4, Insightful)
Sometimes the version numbers are decided upon before the final set of changes has been determined. Often politics get involved, and other external issues. Ie, things like "version 2.5 will be the last one supported on old hardware".
Last place I was at used "major.minor.dailybuild". This got confusing, since every day there was at least one more version to deal with, plus some incremental builds. The build engineer memorized all this stuff, but I could never distinguish 3.1.212 from 3.1.243...
a cautionary tale (Score:3, Insightful)
at my last company, i was part of the new R&D department intended to make us no longer reliant on 3rd party contractors and consultants (which had been going poorly for us). we had multiple product lines with no coherence between any names and numbers. we had a product retroactively named Phase 2, an unrelated product retroactively named Phase 3, and its successor named Phase 3 Version 3, all with what amounted to point releases, without any identified version numbers or names. it was often just difficult to tell what we were talking about.
so when we started working on our own stuff, we did better. we went "major.minor (build)". the head of marketing made a compelling case for being able to decide what was "major" and what was "minor" as far as our clients were concerned, and we thought that was fine. when we were on, say, version 2, we'd have a roadmap for the next several feature/fix packages and say "we think this bundle is version 2.1, this next one is 3.0, then 3.1, 3.2, 4.0". we went 2-5 feature/fix bundles into the future. marketing would come back and say something like "we really need a major-number release earlier than some trade show; make that 3.1, 4.0, and 4.1". some of the engineers were unhappy with this, but i think that's mostly because they discount the validity of marketing and psychology in commercial enterprises generally. in reality, it worked fine.
for about 4 months. then the marketing guys decided to start changing things. frequently. they'd discover some other show they needed to get to, or decide one was less important, or a customer would tell them (stupidly) "we're going to wait for the next major version" or "we don't trust
the biggest problem for engineering was that, again, it was hard to know what we're talking about. when we met to discuss the feature set to put in 3.2, or the planning for 4.0, which 3.2 was that? no good. so we gave up, told marketing that they could simply have the version number all to themselves, and we came up with a unique identifier series to use ourselves: each feature/fix bundle got a volcano name. we could talk about the features in Koko, or decide Krakatoa was too big and break it into Deccan Traps and Viti. we got everyone - including the head of marketing and the CEO - to agree that these were internal-only, engineering-defined designations for feature sets, not tied to published version numbers or whatnot. marketing got nice numbers to show clients, we got reliable, unambiguous identifiers. worked great.
for a little under two years. then we had a review release for the "Kick 'em Jenny" release, where the head of marketing (yes, same one) "asked" us to change the name. R&D had been using it for about six months, so this was reintroducing the same problem we'd invented them to fight off, so, as the engineering manager on the project, i wasn't happy to see this happening, and asked why.
"well," he says, "we can't very well tell that to clients."
"er, right. that's half the point. these are engineering names, remember?" i responded.
"yes, well, the clients like to know the names. we've been telling them all the earlier ones."
(elided arguing and frustration on all sides)
"okay, okay." i said. "a month or two ago, actually, they discovered a near neighbor to Ki