Adam Kennedy wrote:
>>> Also, why exclude v1.23 useful as a tuple...?
>> Belt and suspenders. It might be mistaken for a number. Written as
>> "v1.23.0" it's more obvious that it's a version tuple. And if someone
>> leaves off or strips the "v" for some reason, it's still clearly a
>> tuple and a liberal parser can deal with it without heuristics.
>
> It's got a v... it's a tuple by definition, whether it's got one element or
> 10.
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.
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.
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?
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after eating a junior mint.
-- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
by Tami Farmer
