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

5 of 321 comments (clear)

  1. w/r/t Windows by gcnaddict · · Score: 3, Interesting

    Windows 7 is NT version 6.1, but that's because of appcompat reasons only.

    Microsoft frequently jumps build numbers before milestones (7000 for Beta 1 of Win7, 7600 for RTM)

    Microsoft often picks arbitrary numbers for revision builds (used to be buildnum.0, now it's buildnum.16384 as the starting point. Example: Vista RTM is 6000.16386, meaning there were three compiles of build 6000)

    --
    Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
  2. Don't forget TIFF by Anonymous Coward · · Score: 5, Interesting

    All TIFF files have a version number of 42, chosen, according to the developer docs, for that number's deep philosophical significance.

  3. Re:What now? by JamesVI · · Score: 4, Interesting

    The typical three number scheme is derived from the numbering for shared libraries. Often called Major.Minor.BugFix.
    You increment the BugFix number when you implement a bug fix that makes no changes whatsoever to the interface. You increment the Minor number when you extend the interface (by adding new features). Both of these changes are backwardly compatible so you can just restart an executable that uses the library without having to rebuild or relink.
    If you alter the interface in a non-backwardly compatible way then you must relink your executable before it can work with the new version of the library. The Major number is incremented to indicate a non-backwardly compatible change.

  4. Doom II Version 1.666 by linebackn · · Score: 4, Interesting

    One of my favorite version numbers was the version of the first Doom II executable (which used a different version number than the game itself as it shared the exact same executable with Doom I, Doom I shareware, and Doom II). The initial release of Doom II was "Doom II Version 1.666"".

  5. Starcraft maps by AlpineR · · Score: 4, Interesting

    I release several games as custom maps in Starcraft. Many of them are refinements of earlier versions made by others. And all of them are released unprotected so that others may add their own refinements.

    Version numbers get messy. I typically go to the next major number if I'm doing a serious overhaul of my own or somebody else's map. Then I increment the minor numbers for bug fixes, balance changes, and minor enhancements.

    But then somebody else comes along, makes a minor (and often terrible) change and releases it as the next major version. Or they make major changes and release it as the next minor version. Then when I make a new version, it either clashes with those other versions or looks older than the versions released with big jumps.

    I've tried adding descriptor names to my versions, a la Vista. So I have "Phantom BGH Gold 1.0" as my refinement of "Phantom BGH 2.4", but most people don't seem to get that. When my updates landed me at "Phantom BGH Gold 3.0" people at least paid attention that it might be newer, but they still complained that it was different than "Phantom BGH 2.4".

    I also tried adding "Classic" to a game version which was a totally rewritten implementation of a game type with other versions in the 3.0 to 9.0 range. I intended the "Classic" to signify I was focusing on the core ideas of the game type, but so many people thought it meant "old". As if the first version ever released of that map was labeled "Classic", and a label of "New" means new forever.

    TheNevermind