2009/4/23 Michael G Schwern <schw...@pobox.com>: > Whether you like it or not, humans eyeball version numbers all the time and > they don't think to study the documentation... if they can find it or even > think they might need it to parse something as simple (should be simple) as a > version number. > > Disallowing vX.Y removes an ambiguity into which the user will fall. The best > way to avoid a mistake is to remove the possibility entirely. For example, > when designing a postal code system you remove 1, l, 0 and o because they are > easily confused. Or you interleave numbers and letters, as the Canadians do. > You don't tell your entire population to practice better penmanship.
If we care about humans in the META.yml spec, then fair enough. I agree, in principle. > What if you don't know the definition? What would one think upon encountering > various versions cold? > > v1.2.3 is not a number, it must be a tuple! > > 1.2.3 same deal > > v1.2 its X.Y, that must be a number. > OR > versions in my experience are tuples, so it must be a tuple. > OR > it has a v in front of it, that means... "version"? I dunno. > > > Weighed against this, to which I've gotten no answer, is what is the value of > allowing v1.2 that v1.2.0 does not also offer? Is that value worth opening an > ambiguity in a system that's already full of traps? If we take such an attitude though then we're saying this isn't being written as a machine-consumed document that humans can debug if they need to, but as something that needs to be first-class consumable by humans, then there's no point of having a v at all. We just define two part versions as floats, and three or more parts as tuples, and we're effectively back to the status quo and can be done with it. The v seemingly adds no meaning for the machines, and will just add confusion for the humans. So are you in favour of just a "2 means float, 3 means tuple" approach? Adam K
