Sims version numbering



  • She Who Must Be Obeyed asked for help installing The Sms 3 and updates. She was a little confused about which of these is the later version:

    2.5.12
    2.14.4

    OK, I hadn't had much coffee yet when she asked, but am I the only person who thinks 2.14 is lower than 2.5? EA evidently read that as two-point-fourteen being a higher number than two-point-five. Or is TRWTF expecting sanity from EA?



  • Not surprised EA is one of the places that uses decimal as a separator rather than an actual decimal point, but yeah that would have mixed me up too.



  • TRWTF is anyone expecting decimal points to be anything other then separators when there are obviously two of them in the number.


  • Discourse touched me in a no-no place

    @intertravel said:

    but am I the only person who thinks 2.14 is lower than 2.5?
    No. But then again, those aren't the numbers you're having problems with.



    Version numbers are most certainly not decimal numbers when, as noted, there is more than one period in in the number. (And this whole discussion is predicated on the assumption that everyone uses periods as a decimal separator to begin with - they don't.)



  • The sad posting of a person who has never played Starsiege Tribes.

    Version 1.14 FTW



  • Minor version 14 is obviously later than minor version 5.



  • This sort of numbering is common in games.  World of Warcraft does it, too.  1.16.1 being the last release before the first expansion; and I don't think it's hit a double-digit middle number since (current version is 4.0.6 then some release number that looks suspiciously like a subversion revision number).

    What's even more confusing is the Team Fortress 2 numbering system, where the Steam packages have a single digit version numbers for each package, but the game engine uses a 4 section version number (It's 1.2.x.y now iirc, but I'm at work and can't check; Wikipedia's current TF2 version isn't updated by anyone but me, and I haven't updated it since November).



  • A little while ago I actually had a very similar experience at my own work, when I was designing a software update system for our products. Being relatively new at the time and (incorrectly) assuming they used version numbering like the OP was expecting from The Sims, I had used a simple "parse the number then just use comparison operators to see which is newer." I got yelled at when their app stopped working when we went from 1.9 to 1.10. I explained to them that it's a bit confusing since we really should have started at 1.01. Their answer to that was, "well, what happens after 1.99?"

    If you want to use a version numbering scheme where 9 is less than 10 because it's really a minor version number that's sort of "independent" of the major version number to a certain degree, then I don't understand why one would use "decimal notation" to express the version number. It just creates confusion like the OP and my own experience.



  • @powerlord said:

    This sort of numbering is common in games software.

    FTFY.



  • @RHuckster said:

    A little while ago I actually had a very similar experience at my own work, when I was designing a software update system for our products. Being relatively new at the time and (incorrectly) assuming they used version numbering like the OP was expecting from The Sims, I had used a simple "parse the number then just use comparison operators to see which is newer." I got yelled at when their app stopped working when we went from 1.9 to 1.10. I explained to them that it's a bit confusing since we really should have started at 1.01. Their answer to that was, "well, what happens after 1.99?"

    If you want to use a version numbering scheme where 9 is less than 10 because it's really a minor version number that's sort of "independent" of the major version number to a certain degree, then I don't understand why one would use "decimal notation" to express the version number. It just creates confusion like the OP and my own experience.



    By any chance, do you work on TortoiseSVN?

    Anyway, TortoiseSVN had an issue a year or two ago.  Apparently if you're running 1.6.9 or down, it didn't recognize that 1.6.10 or up were newer versions and didn't tell you that there were any updates available.  Older versions also report than 1.6.9 is available and that you should upgrade to it.



  • @powerlord said:

    By any chance, do you work on TortoiseSVN?

    Anyway, TortoiseSVN had an issue a year or two ago.  Apparently if you're running 1.6.9 or down, it didn't recognize that 1.6.10 or up were newer versions and didn't tell you that there were any updates available.  Older versions also report than 1.6.9 is available and that you should upgrade to it.
     

    Heh, that was just about the time I actually made that mistake. But no, I use TortoiseSVN but I definitely didn't have a hand in developing it. :) I at least have some consolation that I'm not the only guy who made that mistake, though.



  • @RHuckster said:

    A little while ago I actually had a very similar experience at my own work, when I was designing a software update system for our products. Being relatively new at the time and (incorrectly) assuming they used version numbering like the OP was expecting from The Sims, I had used a simple "parse the number then just use comparison operators to see which is newer." I got yelled at when their app stopped working when we went from 1.9 to 1.10. I explained to them that it's a bit confusing since we really should have started at 1.01. Their answer to that was, "well, what happens after 1.99?"

    If you want to use a version numbering scheme where 9 is less than 10 because it's really a minor version number that's sort of "independent" of the major version number to a certain degree, then I don't understand why one would use "decimal notation" to express the version number. It just creates confusion like the OP and my own experience.

     

     That's because it's not actually decimal notation.  Remember that not all people use the same decimal separator.  The "decimal points" are just separators so that you can tell the minor version part appart from the major version number.  The problem is that unless you use a larger character like ; or | or something, you're gonna probably be using a character that is used as a decimal point by someone.



  • @DescentJS said:

     That's because it's not actually decimal notation.  Remember that not all people use the same decimal separator.  The "decimal points" are just separators so that you can tell the minor version part appart from the major version number.  The problem is that unless you use a larger character like ; or | or something, you're gonna probably be using a character that is used as a decimal point by someone.

    That was exactly my point, and why I surrounded it in quotes. If it looks like a duck and it quacks like a duck, then it is a "duck" (in quotes), and people are going to confuse it with a duck. That, coupled with the very arbitary nature of version schemes where every software company seems to homebrew their own (some actually do use 1.05 instead of 1.5, while others might use 1.05.774, and still someone else uses Toy Story characters to express their version, some start with 1.1, but by the time they get to 1.9 and release a new version they don't think is quite a 2.0 yet, they'll make the next one 1.91), makes the whole version scheme a guessing game.



  • @DescentJS said:

    The problem is that unless you use a larger character like ; or | or something, you're gonna probably be using a character that is used as a decimal point by someone.

    And if you do use some weird character like that, you'll just look weird, and people will stop thinking when they see it, and start asking anyways. It's not really different than any sorting procedure that has stored numbers as text.

    Plus using the decimal separator makes it easier to inflate your version number, and go from, say, 1.6 to 1.61. It's less blatant than 1.5 to 6, anyways.


  • Discourse touched me in a no-no place

    @RHuckster said:

    That was exactly my point, and why I surrounded it in quotes. If it looks like a duck and it quacks like a duck, then it is a "duck" (in quotes),
    And the point some of us are making is any number with two (or more) periods within it doesn't quack like a decimal number, since in a decimal number there is only one decimal marker.



    Unless you know of some significantly popular formatting scheme somewhere in the world where more than one decimal marker is allowed in a floating point number? (Of course, any versioning system that includes only a major and minor number will be ambiguous out of context since there will be only one separator.)

    @RHuckster said:
    the very arbitary nature of version schemes where every software company seems to homebrew their own (some actually do use 1.05 instead of 1.5, while others might use 1.05.774, and still someone else uses Toy Story characters to express their version, some start with 1.1, but by the time they get to 1.9 and release a new version they don't think is quite a 2.0 yet, they'll make the next one 1.91), makes the whole version scheme a guessing game.
    No argument there.



  • @PJH said:

    @RHuckster said:
    That was exactly my point, and why I surrounded it in quotes. If it looks like a duck and it quacks like a duck, then it is a "duck" (in quotes),
    And the point some of us are making is any number with two (or more) periods within it doesn't quack like a decimal number, since in a decimal number there is only one decimal marker.
     

    You're right it doesn't quack like a decimal number, but OP was saying earl/not paying attention at which point confusing duck quack with another kind of quack is understandable.  Main issue is that it's far enough from decimal that if you are looking for version you see version, but if non-technical or low attention it is close enough to trip you up.  Of course I've no idea what could work better for version numbers.



  • @PJH said:

    And the point some of us are making is any number with two (or more) periods within it doesn't quack like a decimal number, since in a decimal number there is only one decimal marker.
     

    It doesn't quack, no. The duck just has one of those quack noise makers hunters use. If you are paying attention, it's obviously not a real quack, but if you're not, then you can make an incorrect assumption. One could also argue that, although there are two "dots" in it (obviously meaning to anyone who's graduated grade school that it's not a floating point number) that doesn't automatically make one assume that it's not trying to be otherwise analogous to a decimal number. Or, heck, in some cases you could even mistaken a version number with two points with a date if it's close enough. In the OP, 2.5.12 could mean a release on February 5th, 2012 without any other context.

    As you and I agree, though, the arbitrary nature of version numbers will cause confusion regardless of the symbol that's used. I think I adopted the idea that there was some kind of "decimal usage" the moment Windows came out with 3.11 as the next release after Windows 3.1, and when the next version came out to be 3.2, that reinforced my assumptions pretty well. From that day on, I decided to keep those assumptions until the day I was burned.



  • @RHuckster said:

    If you are paying attention, it's obviously not a real quack, but if you're not, then you can make an incorrect assumption. One could also argue that, although there are two "dots" in it (obviously meaning to anyone who's graduated grade school that it's not a floating point number) that doesn't automatically make one assume that it's not trying to be otherwise analogous to a decimal number. Or, heck, in some cases you could even mistaken a version number with two points with a date if it's close enough.

    Yeah, I doubt I'd have made the same mistake had I been a bit more awake. It does occur to me, though, that being EA they might be daft anyway: 2.14.xx could mean major version 2, minor version 14, revision xx, but it might also mean major version 2, minor version 1, variant 4, revision xx.

    Thinking about it a little more, I'd say that if you get to 2.9, your next version should be 2.91, and so-on. I wonder if there was a version 2.10, or if they thought it would be too confusing to have that and 2.1 mean different things.



  • @derula said:

    @powerlord said:
    This sort of numbering is common in games software.

    FTFY.

    And hardware, too. Our circuit schematics use version.branch.revision numbering (with repeated branches, if necessary). 2.1.9 is followed by 2.1.10.



  • @derula said:

    @powerlord said:
    This sort of numbering is common in games software.

    FTFY.

    Yes, I would advise against using apache 2.2.3 instead of 2.2.17



  • @PJH said:

    @RHuckster said:
    That was exactly my point, and why I surrounded it in quotes. If it looks like a duck and it quacks like a duck, then it is a "duck" (in quotes),
    And the point some of us are making is any number with two (or more) periods within it doesn't quack like a decimal number, since in a decimal number there is only one decimal marker.



    Unless you know of some significantly popular formatting scheme somewhere in the world where more than one decimal marker is allowed in a floating point number? (Of course, any versioning system that includes only a major and minor number will be ambiguous out of context since there will be only one separator.)

    @RHuckster said:
    the very arbitary nature of version schemes where every software company seems to homebrew their own (some actually do use 1.05 instead of 1.5, while others might use 1.05.774, and still someone else uses Toy Story characters to express their version, some start with 1.1, but by the time they get to 1.9 and release a new version they don't think is quite a 2.0 yet, they'll make the next one 1.91), makes the whole version scheme a guessing game.
    No argument there.
    I saw this happen to one project; 1.9 was updated, too significantly to call it 1.91, but not enough to be 2.0. Solution? Consider the version numbers hexadecimal and move to version 1.A, 1.B, 1.B1...



    I like to just use a build ID which encodes the current date into bitfields: yyyyyyyy yyymmmmd ddddiiii where i is usually zero but increments if there are multiple releases in a day, and y is year - 2000. The resulting 5-digit numbers (or 4-digit if you use hex, but that can be confusing) don't really say much about the amount of change from one version to the next, but that's what changelogs are for.



  • Or you can just adapt TeX's version numbering: pick a transcendental number (I guess any irrational number would be OK, really) and each released version gets one more digit of the number added. Extra fun for support calls.



  • @lolwtf said:

    I like to just use a build ID which encodes the current date into bitfields: yyyyyyyy yyymmmmd ddddiiii where i is usually zero but increments if there are multiple releases in a day, and y is year - 2000. The resulting 5-digit numbers (or 4-digit if you use hex, but that can be confusing)

    I don't see how you can compress 3 bytes into 4 hex digits unless you omit leading zeroes and you never use your encoding scheme after the year 2007...



  • @intertravel said:

    OK, I hadn't had much coffee yet when she asked, but am I the only person who thinks 2.14 is lower than 2.5?
     

     

    You obviously never had to do with software versioning, isn't it.

    I remember an application that made documents versionning, in format x[.y[.z[...]]]. Used everywhere as a string in codebase. Someone very "clever" in the developpement team designed the oracle database schemas by using a "decimal number" column. Went well until a user decided to create a document in version 1.2.1 ..... Was never fixed.

     

    And by the way, i don't use "." as a decimal separator in my country :D

     



  • @intertravel said:

    OK, I hadn't had much coffee yet when she asked, but am I the only person who thinks 2.14 is lower than 2.5?
     

    I must admit that I never doubted that 2.14.x is bigger (later) than 2.5.x

    As others have pointed out, these are not decimal separators, but just separators.

    Think of IP-addresses.



  • I've always thought of the dots as separators, and have no problem with the second or third element being larger than 9. For instance, Mac OS X Tiger went up to 10.4.11. That being said, some code has trouble with those, for instance the 'vers' versioning resource, which is the traditional Mac mechanism for declaring the version number, relies on BCD and so had trouble when a game I know updated to 1.0.10: it was sometimes shown as 1.0.A…

    It also doesn't help at all when some software jumps to .5 as some sort of intermediate update, to give the impression of being "midway through" to the next major one: think Windows Mobile 6.5, System 7.5 and Mac OS 8.5, Firefox 3.5, etc, etc, etc. none of which previously had a X.4(.0) version.


  • Discourse touched me in a no-no place

    @ZPedro said:

    and have no problem with the second or third element being larger than 9.
    Some people do - I seem to remember lots of problems when Adobe increased their major version to 10. (Mainly javascript that either checked for a single digit major version, or just checked the first digit.)



  • @ZPedro said:

    no problem with the second or third element being larger than 9. For instance, Mac OS X Tiger went up to 10.4.11.
     

    They're going to run out of big cats, though.



  • @dhromed said:

    @ZPedro said:

    no problem with the second or third element being larger than 9. For instance, Mac OS X Tiger went up to 10.4.11.
     

    They're going to run out of big cats, though.

    I think that their bigger problem is with what they are going to do when they finally increment their version number to 11. No longer would they be Mac OS X, but rather Mac OS XI. It just doesn't have the same ring to it. As an aside, their upcoming [url=http://www.apple.com/macosx/lion/]Lion[/url] version is nothing more than a kitten with regard to new features. Basically it's just converting the desktops into iPad wanna-bes. Boo!



  •  They might do something completely different, like 'Y', or bastardize XI into X-1.



  • @dhromed said:

    @ZPedro said:

    no problem with the second or third element being larger than 9. For instance, Mac OS X Tiger went up to 10.4.11.
     

    They're going to run out of big cats, though.

    There's hundreds of extinct ones. (Only a few have recognizable names, though...) OS X Smilodon.



  • @dhromed said:

     They might do something completely different, like 'Y', or bastardize XI into X-1.

    X Minus 1? Awesome.



  • @Scarlet Manuka said:

    Or you can just adapt TeX's version numbering: pick a transcendental number (I guess any irrational number would be OK, really)

    Works with certain rational numbers too.



  • @RHuckster said:

    If you want to use a version numbering scheme where 9 is less than 10 because it's really a minor version number that's sort of "independent" of the major version number to a certain degree, then I don't understand why one would use "decimal notation" to express the version number. It just creates confusion like the OP and my own experience.
    The problem is that technically its not really decimal notation -- you're just using a period as a separator between the major and minor version numbers.  But, if you live somewhere that uses a period as the decimal separator then your brain tends to automatically see it as a decimal number anyway,  and one of the rules of decimal numbers is that on the right side of the decimal point trailing zeros are insignificant, i.e., 4.50 is the same as 4.5.   And that's actually the basis for the whole version numbering system -- why is 1.01 considered a minor change and 1.1 is considered a bigger change?  Because your brain automatically sees 1.1 as 1.10 and "10" is greater than "01". 

    So there is confusion when someone decides to go from 4.9  to  4.10  because your brain tends to automatically see 4.9 as 4.90 which is greater than 4.10

    @RHuckster said:

    I explained to them that it's a bit confusing since we really should have started at 1.01. Their answer to that was, "well, what happens after 1.99?"
    1.99.01  or  2.0



  • @El_Heffe said:

    @RHuckster said:
    I explained to them that it's a bit confusing since we really should have started at 1.01. Their answer to that was, "well, what happens after 1.99?"
    1.99.01  or  2.0
    How about avoiding ambiguity? 1.10 may or may not be a higher version number than 1.9, but 1.91 is unambiguously higher. When you get to 1.99, you can go for 1.991 (or 2.x).

    What's the point of having a system where you have to parse the version number carefully to work out which digits are significant, instead of just being able to use the conventional assumption that digits decrease in significance from left to right.



  • @RHuckster said:

    A little while ago I actually had a very similar experience at my own work, when I was designing a software update system for our products. Being relatively new at the time and (incorrectly) assuming they used version numbering like the OP was expecting from The Sims, I had used a simple "parse the number then just use comparison operators to see which is newer." I got yelled at when their app stopped working when we went from 1.9 to 1.10. I explained to them that it's a bit confusing since we really should have started at 1.01. Their answer to that was, "well, what happens after 1.99?"

    If you want to use a version numbering scheme where 9 is less than 10 because it's really a minor version number that's sort of "independent" of the major version number to a certain degree, then I don't understand why one would use "decimal notation" to express the version number. It just creates confusion like the OP and my own experience.

     

    So were you surprised that when you assigned IP addresses, the number after 192.168.0.9 was 192.168.0.10 instead of 192.168.1.0?

    If you email a buddy in Vancouver at someone@bc.ca, would you expect the next address to be someone@bd.ca, or someone@bc.cb? (ok, that one was abusing/stretching the analogy, even for me!).

    I guess I'm just used to the major.minor.patch format of version numbering, especially the idea of "rules" for assigning or incrementing version numbers. In my experience, a jump from 1.9 -> 2.0 implies "get ready for an entirely new UI (Firefox) or backend DB (peachtree) etc." and a jump from 1.9 -> 1.10 means something like "whew, we fixed that security hole".

     



  • @RichP said:

    So were you surprised that when you assigned IP addresses, the number after 192.168.0.9 was 192.168.0.10 instead of 192.168.1.0?
     

    No, for the simple reason that IP addresses have a well-defined, blatantly-documented format and standard.

    Some companies indeed treat version numbers as if they were decimal numbers, which as I indicated before, was how I presumed at an early age that's how they were done. I knew that one would treat a "whole number" increase as a major release, and one would often skip numbers either to "feel even better than the competition (Netscape vs IE)" or as a marketing gimmick.



  • @RichP said:

    So were you surprised that when you assigned IP addresses, the number after 192.168.0.9 was 192.168.0.10 instead of 192.168.1.0?
    No, because IP addresses are something entirely different.  Nobody is comparing one IP address to another to see which one is newer.

    On a semi-unrelated subject, this thread reminded me of the olden days when I was using Wordperfect and discovered that they had released 3 different verisons over a period of about 18 months, but they were all labeled as version 5.1, and each newer version had features that weren't present in the older verions, which resulted in the ability for a person using WP 5.1 to create files that couldn't be read properly by another person who was also using WP 5.1.  The only way you could tell which version you had was to look at the dates on the program files.



  • @RichP said:

    So were you surprised that when you assigned IP addresses, the number after 192.168.0.9 was 192.168.0.10 instead of 192.168.1.0?
    IP addresses aren't simple integers, they're dot-separated co-ordinates for a four-dimensional space - or, if you prefer, four digit numbers in base-256, written in a funny way. I suppose when you put it that way, version numbering like 1.9 -> 1.10 is actually not in base-ten. Again, that's using dots to separate non-base-ten numbers written in a way that can use (one or) more than one character to represent each digit.

    @RichP said:

    If you email a buddy in Vancouver at someone@bc.ca, would you expect the next address to be someone@bd.ca, or someone@bc.cb?
    No. Email addresses aren't sequential, incremental, what-have-you. Version numbering is (supposed to be).



  • @intertravel said:

    @RichP said:
    So were you surprised that when you assigned IP addresses, the number after 192.168.0.9 was 192.168.0.10 instead of 192.168.1.0?
    IP addresses aren't simple integers, they're dot-separated co-ordinates for a four-dimensional space - or, if you prefer, four digit numbers in base-256, written in a funny way. I suppose when you put it that way, version numbering like 1.9 -> 1.10 is actually not in base-ten. Again, that's using dots to separate non-base-ten numbers written in a way that can use (one or) more than one character to represent each digit.

    @RichP said:

    If you email a buddy in Vancouver at someone@bc.ca, would you expect the next address to be someone@bd.ca, or someone@bc.cb?
    No. Email addresses aren't sequential, incremental, what-have-you. Version numbering is (supposed to be).
     

    To be more precise, IPV4 addresses are each a single 32-bit number, commonly expressed in a funny way, and (often? sometimes?) understood to be a two dimensional space (network and host). Like I said, the email analogy is a reach. What I was getting at is we're surprisingly used to treating the dot as an arbitrary separator in other scenarios.

    Here's another way to think about the original question, would the following sequence of version numbers seem unusual? 

     1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 3.0....

     On the one hand, the first part of the sequence could imply our version system is base-4, so version 3.4 must be followed by 4.0. On the other hand, if we assume the numbers are base-10, for some reason we don't find the lack of version 1.4 to be glaring.

    I'm sure there's someone out there studying human perception of numeric data that can explain why we have some of those perceptions. I'm content to marvel at them (both the perceptions and the people with time to study them!)

     


  • Discourse touched me in a no-no place

    @RichP said:

    1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 3.0....

     On the one hand, the first part of the sequence could imply our version system is base-4, so version 3.4 must be followed by 4.0.

    ITYM base-5.



  • @RichP said:

    On the one hand, the first part of the sequence could imply our version system is base-4, so version 3.4 must be followed by 4.0. On the other hand, if we assume the numbers are base-10, for some reason we don't find the lack of version 1.4 to be glaring.
    Again, though, there's no ambiguity. Whichever base they're in, 4.0 is larger than 3.3.

    @RichP said:

    I'm sure there's someone out there studying human perception of numeric data that can explain why we have some of those perceptions.
    I'm not sure it's that complicated, really. With just one IP address, it's an arbitrary string. With two consecutive IPs, I would tend to think of them as [firstpart].1, [firstpart].2, etc., so I know which part to compare with which other part, the convention by which the larger one is signified, and so-on. It all happens easily because I'm used to doing it. If I have to stop and work out how all that works, it's obviously a bit more mental effort.

    As I said, what's bugging me is that I can't think of a single advantage of following 1.9 with 1.10 instead of 1.91.



  • @RichP said:

    I'm sure there's someone out there studying human perception of numeric data that can explain why we have some of those perceptions. I'm content to marvel at them (both the perceptions and the people with time to study them!)

     

    All of our perceptions are based on past experience, of course. Someone who has math experience but absolutely no musical experience might look at a time signature, which appears identical to a fraction, and make incorrect assumptions as to what it means. The same can be said about virtually everything else that, on the outside looks the same, but is in reality apples and oranges. To a person who has seen apples his entire life, an orange just looks like a strange apple until he peels it and takes a taste of it. Then he realizes he's wrong, people make fun of the poor guy and then he hangs himself. It's sad, really.



  • @intertravel said:

    As I said, what's bugging me is that I can't think of a single advantage of following 1.9 with 1.10 instead of 1.91.

    Well, there's the obvious: version + 1 as opposed to version + 82. One reason this is an advantage is that it's easier to determine the "space" between versions. Pretty soon, you might start having 1.993. Not that version numbers have to (or even usually) make sense.



  • @RHuckster said:

    No, for the simple reason that IP addresses have a well-defined, blatantly-documented format and standard.

    Amusingly enough, there isn't really an official Internet standard that defines the textual representation of IPv4 addresses; although I guess the POSIX page for [url=http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html]inet_addr[/url] is definitive enough.



  • @boomzilla said:

    @intertravel said:
    As I said, what's bugging me is that I can't think of a single advantage of following 1.9 with 1.10 instead of 1.91.

    Well, there's the obvious: version + 1 as opposed to version + 82. One reason this is an advantage is that it's easier to determine the "space" between versions.
    For that to be true, though, doesn't there need to be some sort of convention about how versions are numbered? At the moment everyone just does what they want. The size of the change should be indicated by which part of the version number has been incremented, though, in my book.



  • @intertravel said:

    @boomzilla said:
    @intertravel said:
    As I said, what's bugging me is that I can't think of a single advantage of following 1.9 with 1.10 instead of 1.91.

    Well, there's the obvious: version + 1 as opposed to version + 82. One reason this is an advantage is that it's easier to determine the "space" between versions.
    For that to be true, though, doesn't there need to be some sort of convention about how versions are numbered? At the moment everyone just does what they want. The size of the change should be indicated by which part of the version number has been incremented, though, in my book.

    Obviously, it's not a standard or anything. Nor would it ever be possible to make one. The major / minor / patch version is usually more significant, true, but irrelevant to this point. Anyways, you asked for an advantage, and from the other extreme of arbitrary codewords, it does convey some information.



  • @boomzilla said:

    Anyways, you asked for an advantage, and from the other extreme of arbitrary codewords, it does convey some information.
    I could see a difference - I was just questioning whether it's actually an advantage :)



  • @derula said:

    @Scarlet Manuka said:
    Or you can just adapt TeX's version numbering: pick a transcendental number (I guess any irrational number would be OK, really)
    Works with certain rational numbers too.
    The problem with rational decimals is that they repeat. To take your example, it's much easier to confuse version 1.111111 with version 1.1111111 than it is to confuse version 1.438480 with version 1.4384805.

    Though I suppose with any irrational number you'll get confusion when you add a 0 digit, e.g. between 1.43848 and 1.438480. I suppose you could adapt the rule to say that whenever you add a zero digit, you keep adding digits until you get to a non-zero one.



  • @Scarlet Manuka said:

    @derula said:
    @Scarlet Manuka said:
    Or you can just adapt TeX's version numbering: pick a transcendental number (I guess any irrational number would be OK, really)
    Works with certain rational numbers too.
    The problem with rational decimals is that they repeat.

    But, for any given natural number n, you can find a rational number q such that the first n decimal places of q have no obvious pattern repeated. So just let n = max { numbers of versions you could ever imagine you'd possibly make } * 10, find an appropriate rational number and... voilà! as soon as you roll the (10 * (max number of versions you could have ever imagined you'd possibly make))th version, all the following versions will just add a 0!


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.