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?)"
I'm no coder but to me the X.Y.Z format has always been where Z = minor bug fixes, Y = new features, more bugfixes, whatever, and X = major new features and such.
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.
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.
> 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.
Sleep your way to a whiter smile...date a dentist!
Much of this is really up to marketing. I've seen big sets of bug fixes without new "features" cause a "1.1.1 -> 1.2.0" release, as long as marketing sees this as a relatively important release. I've also seen new features end up as only minor version changes "1.1.1 -> 1.1.2" if the marketing sees this as minor or not worth a bullet point in their talking points.
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...