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?)"
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!