• Little Bobby Tables (unregistered)

    vresion 0.0.0

  • LCrawford (unregistered)

    E=MC1.94? It looks like each developer has been assigned their own range for release generation, which is applicable in some situations (generally with older software configurations).

  • Anonymous Lizard (unregistered)

    I don't believe it. This looks like the submitter run 'git tags' without specifying the correct sorting order.

    Which isn't really the WTF, the number of people who know how to do it is much smaller than the number of people who don't.

  • bvs23bkv33 (unregistered)

    Three shall be the version thou shalt count, and the number of the version shall be three. Shalt thou not count to verion four, neither version number should be two, excepting that thou then proceed to version three.

  • EwgB (unregistered) in reply to Anonymous Lizard

    Doesn't make it a whole lot better. There are e.g. eight versions v2.4.2, which is kinda defying the whole point of versions.

  • (nodebb)

    one developer down in the basement decides to fork and not tell anyone

    When you find out, you kick him in the head until he stops doing it, or until he stops breathing, whichever comes second.

  • apeljohn (unregistered)

    I think I'm going to start recommending this post as reading material for new recruits in need of version control inculcation. Excellent summary.

  • (nodebb)

    TRWTF is the missing v on one of the versions.

  • SG (unregistered)

    Hmm. Better than in my company...

    C++: There is a file containing the BUILD number, created in the Post-Build event. This Build number file is included in the overall header (yes, this on its own is a WTF) file. -> Every (successful) compile will leas to a recompile everything next time. This Build Number is the last of the four numbers ( 1.0.0.234321). But the only one allowed to check in the file is the old developer (There are big jumps in this number..).

    But there is a build server: The build server puts the build server build number at the third place (1.0.213.234321). So, if you discover a version with a "0" at the client - this was private build..

    At least -this system guarantees raising numbers - except a novice checks this file in...

    (And yes - I disabled the Post Build event on my machine. But now, I have a lot of double check ins: First with new files, second just the project file..)

  • CodeMonkey (unregistered)

    vresion 1.0.1 - which is obvious being prior to frist comment

  • (nodebb)

    Simpler remedy: Simply don't use anything in that developer's fork. That's their private playground.

  • (nodebb) in reply to Steve_The_Cynic

    Simpler remedy: Simply don't use anything in that developer's fork. That's their private playground.

  • HK-47 (unregistered)

    Real programmers’ code has only one version - 1.0.

  • David C. (unregistered)

    A fairly reasonable approach (at least to me) is what one employer did. They used a version control system (Perforce) that numbered all commits sequentially, across all products and branches on the server.

    The version number was of the form x.y.z.bbbbbb, where "x.y.z" is a traditional version number, assigned by product management to represent major.minor.patch releases. And "bbbbbb" is the commit number from version control corresponding to what was actually compiled by the build system. So if a customer includes the version number in a bug report, it is trivially easy to create a build with that exact code for the purpose of testing and bug fixing.

    And if a customer needs a custom build, his branch inherits the same "x.y.z" version, number but gets a new commit number, corresponding to his branch. Or even if it's in the same branch, because the build environment (references to compilers, components, etc.) were all checked in alongside the sources.

    I'm sure people will suggest alternatives, and this approach was far from perfect, but it worked well for our purposes. Higher-numbered versions were always more recent than lower-numbered versions, and custom builds would always result in different numbers, so there would never be confusion about what specific version applied to a reported bug.

  • Supersonic Tumbleweed (unregistered)

    Looks like someone tried to push to version v1.3.3.7 just for the kicks

  • iWantToKeepAnon (unregistered) in reply to bvs23bkv33

    And five is right out

  • ooOOooGa (unregistered) in reply to HK-47

    Yes.

    And any actual, existent programmer who attempts this will also only need one version number -- 0.1.

  • sizer99 (google)

    I've seen worse than this. Badness here 1) multiple releases with the same version (cardinal sin #1), 2) versioning is apparently manual (cardinal sin #2) and sometimes people forget the v or the third digit, 3) they decided to throw everything out and start over again at v0.1 (complete rewrite?).

    Other than that it basically goes up though. I've seen places where version 3.2.4 is actually later than 3.2.6 and has bugfixes 3.2.6 doesn't - because of the branch problem Remy mentioned. Places where they decide 3 digits isn't enough (sometimes it isn't) and switch to alpha, like 2.6.2c, and of course the alpha are manually assigned and inconsistent, and then yes, someone needs a fix release for 2.6.2c but there's already a 2.6.2d, so you get a 2.6.2ca. Places where they auto-version it but it always installs as version 1.1 since they don't know how to get the version info from the build/exe to the installer.

  • Zach (unregistered)

    And this is why for all of my products we don't use version numbers and force the client to guess which version they are on and we don't do any bug fixes until they can figure it out. Good luck dealing with that WTF!

  • Gnasher729 (unregistered)

    Apple’s App Store makes such nonsense impossible. They just don’t accept any apps with version numbers that are not in increasing. If you released version 1.4.13, they won’t accept 0.x, 1.3.x, 1.4.12 or 1.4.13 again. Just don’t let some idiot release version 99.0.

  • richarson (unregistered) in reply to Mr. TA

    I think TRWTF is that Remy didn't link to the obligatory XKCD (or we don't do that anymore?):

    https://xkcd.com/1172/

  • SplatmanDeux (unregistered)

    Document management at my company is specified as:

    1. Document starts at version x.1, where x is +1 the previous version of the document. e.g. updating 1.0 results in version 2.1
    2. Each rev before final approval increases the minor version e.g. 2.1, 2.2, 2.3
    3. When the final revision is approved, it becomes the .0 version, e.g. 2.0
  • (nodebb) in reply to iWantToKeepAnon

    Once the number three, being the third number, be reached, then, lobbest thou thy version towards thy customer.

  • Christian (unregistered)

    Well, the release numbers are ordered, so they are not a total random. My suspicion is that when they went from V3.0 to V0.1 they rebranded their product (maybe making some heavy changes along the way). Maybe they didn't want their "new" product to start with V3 something.

    Why all Version except 1.3.5 are prefixed with a "v" is really beyond me however ;)

    cheers

  • Klaus (google) in reply to SplatmanDeux

    In a way, that document versioning seems perfectly consistent. Pretty confusing, especially if you ever hire contractors or give any of those documents to customers, but consistent.

    ... so, how often does someone accidentially do "2.1, 2.2, 3.0" instead of "2.1, 2.2, 2.0"? :)

  • Little Bobby Tables (unregistered)

    "multiple releases with the same version (cardinal sin #1)"

    ... a.k.a. "Oops, released a version with a silly mistake in it -- quick, release another one with the same number so nobody notices. Oops, made a mistake in that one too ... oh dear ..."

  • Little Bobby Tables (unregistered)

    "for all of my products we don't use version numbers and force the client to guess which version they are on "

    Any product that I design has a well-defined version number which is prominently placed on the page footer of every page of the product the user visits.

    Doesn't do any good, though.

    "I've got a bug in (xxx app)." (and at this point they may or may not describe the bug, and may or may not relate the bug message to me.)

    "Okay," I reply, "what version are you running?"

    "I don't know!"

    "It's on the footer."

    "I can't be bothered to read the footer! Just fix my bug!"

  • Dlareg (unregistered)

    In my teens I developed a small program which did calculations for some small telnet game. I had a whole 0 downloads a week. My versions were 3 3. 3.1 3.14

    Etc Etc

  • Little Bobby Tables (unregistered) in reply to Dlareg

    Yeah Donald Knuth implemented a versioning technique along those lines when he developed TeX. Can't remember the details, but one subset of this product uses the digits of pi, and another uses the digits of e.

  • 3stdev (unregistered) in reply to Little Bobby Tables

    I wish there was either a 'Like' or 'Upvote' button so I could click it for this comment.

  • Wizard (unregistered) in reply to Christian

    Not sure about rebranding - the fact it went to version 0 sounds more likely to me that some "clever" consultant came and said "its a pile of pooh. So we're going to rewrite the entire codebase and we'll do it in a structured way by rewriting the classes starting with those being with the letter A...."

    I'm sure several businesses must have experienced that nightmare...

  • (nodebb)

    SmartEiffel, the GNU Eiffel compiler, was once called SmallEiffel. The version numbers started at -0.99 (yes, minus zero point nine nine), was were incremented towards zero. The idea was that SmallEiffel 0.0 would be the final ideal compiler!

    Most systems however treat the minus as a separator, and directory listings and other things would order the things in an exactly opposite order. They also may have realized that there is no such thing as the final ideal version. They aborted this numbering at around -0.74 (minus zero point seven four), changed the name to SmartEiffel, with version number 1.0.

    On their download page ( https://gforge.inria.fr/frs/?group_id=184 ) you can see the versions starting from -0.90.

  • Dkresh (unregistered)

    I would very much like to hear those conversations with distressed customers:

    Emp: "Which version are you on?" Cust: "I just upgraded to v1.0.4" Emp.: "I see. And what version of V.1.0.4? The one after V.1.0.3 or the one after v.1.0.5" Cust.: "Wait? Uhm? What?" Emp.: "Never mind, just downgrade tot V.3.0.1, that'll do the trick"

  • PotatoEngineer (unregistered)

    The other reason why version numbers don't increment: contracts.

    I once worked at a company that promised that "the 2.7.x releases" would be free, and that the client would pay starting at "version 2.8.0". My company was a startup. The client was a) the only customer, and b) enormous. My company shipped "version 2.7.x" waaaaay longer than the code had any right to be called 2.7.x, because the client had all the power.

  • me (unregistered)

    Do you know WinDBG from Microsoft? The "old versions" were rather broken with version 5.x (or so). Thus, Microsoft started over, creating a version 1.0. This added much to the confusion. It does not help mich that this was the official debugger for any kernel-mode component of Windows.

  • jgh (unregistered)

    I've recently had to bodge some reporting code because version numbers are supposed to be BCD ab.xy (eg 0123 = v1.23) but somebody broke something and created a handful of bz.xy (eg 3456 = v3.56d).

  • (nodebb)

    Our product has been on the same major version for years, even though there would have been at least three occasions to bump it up according to semver. We are releasing more breaking changes soon, all the developers are pushing to increase it, but the PTBs are still resisting. I think it was because our last proper x.0 release there was a fair number of problems and they don't want a repeat! (One of the product owners was the main support person back then and he still wakes up in a cold sweat reliving the support calls)

    For development, private and POC builds we use x.y.z-hash where hash is the truncated md5 of the branch, which becomes x.y.z-rc1 before release x.y.z. the z is almost always 0 in this case. With our current process a date-based system would make more sense, and I'd prefer a commit hash rather than branch hash... But currently have a version file committed so updating that changes the head commit... This is another deceptively "simple but complex" problem to solve!

  • smf (unregistered)

    You should have a single version number sequence and include the customers name in the software name.

    Then try to get customers to take the latest whenever they are taking new functionality, but allow minor bug fixes in their branch and add a suffix to the version.

    If the version is buggy enough that it requires a large rewrite/retest then persuade them to go to the latest & make sure you actually fix it properly.

  • (nodebb) in reply to Little Bobby Tables

    My own company did this for a time, but I managed to restrict it to odd version numbers (which basically mean "This is dev-only code, and if the client sees it, it's because it's an emergency quick&dirty patch". Even version numbers are (at least in theory) guaranteed unique, because the version is increased again immediately after publishing.

  • (nodebb) in reply to sizer99

    Other than that it basically goes up though. I've seen places where version 3.2.4 is actually later than 3.2.6

    I thought the same as you, until I read a little closer.

    After starting again at 0.1, they find they need to start again again, so they go from 0.1.2 to 0.0.1 and thence to 0.0.5 before resuming at 0.2. After 1.0.3 they have 1.0.4 and 1.0.5, and then 1.0.4 again and 1.0.5 again before we finally get to 1.0.6. After 1.3.6 they go back to 1.3.5 again before jumping to 1.3.7. (At least they didn't repeat 1.3.6 as well this time.)

    So yeah, it's a mess.

  • John Długosz (unregistered)

    I think I will start using (only) emoji characters for my version identifiers.

Leave a comment on “Relative Versioning”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article