[Citation date: Wed, 6 Dec 1995 16:52:22 +0000]
TB == Tim Bunce <Tim.Bunce@ig.co.uk>
TB> 1.0.4 is not a 'standard' module version number. See the Module List
TB> and Exporter.pm.
Sorry to start out inflamatory, but why did Perl use such a bogus standard
for version numbers? All the world thinks that 3 or 4 level version numbers
(like 1.0.4) are perfectly reasonable and understandable, and as a result,
are heavily used in practice. The problem is in the 99-rollover; given two
version numbers like 3.78 and 3.152, which is the more recent? I don't
believe I should have to roll over to 4.00 once I reach 3.99 simply because
the perl versioning standard wasn't far-thinking enough.
IHMO, the excuse of numerical comparison is a poor one. One of my favorite
quotes reflecting my development philosophy (courtesy of Larry) is "Given a
choice between making things easy for the computer or easy for the user, the
computer usually loses"; this forced two-level versioning standard certainly
sacrifices ease-of-use and understandability for the sake of an "easier to
implement" comparison. Granted, I haven't actually run into the "greater
than 99" version problem in any of my current perl development, but I'd be
willing to bet than many developers here have worked on large,
multi-developer projects where it is almost a necessity to have sub-versions
greater than 99, even neglecting 3-level numbers.
Does it seem possible to create a version comparison function which is able
to intelligently compare both 2-level and 3-level version numbers? I
haven't fully thought that aspect through yet, but if it is possible, are
there strong reasons not to migrate Exporter.pm and MakeMaker.pm to a
revised standard? As long as the comparison function does the "right thing"
for 2-level version number comparisons in which the second levels are less
than 99, I don't see why we shouldn't make the standard more generally
useful. Neglecting that, would I be chastised according to the "standard"
were I to implement a greater-than-99 and 3-level-aware require_version for
my own development?
BTW, I would claim that the current standard is not adequately documented.
There are a couple of examples scattered here and there, but none of the
text mentions that version numbers have to be able to be able to be compared
by the '<' operator. I think even developers who are diligent in reading
the documentation will continue to assume that 3.252 is greater than
3.15 or that 3-level version numbers will work.
--
jared@organic.com / Organic Online / <URL:http://www.organic.com/Staff/jared/>
"Fornicate and take drugs against the terrible strain of idiots who govern
the world."
-- Albert Szent-Gyorgyi, Nobel Laureate in Medicine and Physiology
TB == Tim Bunce <Tim.Bunce@ig.co.uk>
TB> 1.0.4 is not a 'standard' module version number. See the Module List
TB> and Exporter.pm.
Sorry to start out inflamatory, but why did Perl use such a bogus standard
for version numbers? All the world thinks that 3 or 4 level version numbers
(like 1.0.4) are perfectly reasonable and understandable, and as a result,
are heavily used in practice. The problem is in the 99-rollover; given two
version numbers like 3.78 and 3.152, which is the more recent? I don't
believe I should have to roll over to 4.00 once I reach 3.99 simply because
the perl versioning standard wasn't far-thinking enough.
IHMO, the excuse of numerical comparison is a poor one. One of my favorite
quotes reflecting my development philosophy (courtesy of Larry) is "Given a
choice between making things easy for the computer or easy for the user, the
computer usually loses"; this forced two-level versioning standard certainly
sacrifices ease-of-use and understandability for the sake of an "easier to
implement" comparison. Granted, I haven't actually run into the "greater
than 99" version problem in any of my current perl development, but I'd be
willing to bet than many developers here have worked on large,
multi-developer projects where it is almost a necessity to have sub-versions
greater than 99, even neglecting 3-level numbers.
Does it seem possible to create a version comparison function which is able
to intelligently compare both 2-level and 3-level version numbers? I
haven't fully thought that aspect through yet, but if it is possible, are
there strong reasons not to migrate Exporter.pm and MakeMaker.pm to a
revised standard? As long as the comparison function does the "right thing"
for 2-level version number comparisons in which the second levels are less
than 99, I don't see why we shouldn't make the standard more generally
useful. Neglecting that, would I be chastised according to the "standard"
were I to implement a greater-than-99 and 3-level-aware require_version for
my own development?
BTW, I would claim that the current standard is not adequately documented.
There are a couple of examples scattered here and there, but none of the
text mentions that version numbers have to be able to be able to be compared
by the '<' operator. I think even developers who are diligent in reading
the documentation will continue to assume that 3.252 is greater than
3.15 or that 3-level version numbers will work.
--
jared@organic.com / Organic Online / <URL:http://www.organic.com/Staff/jared/>
"Fornicate and take drugs against the terrible strain of idiots who govern
the world."
-- Albert Szent-Gyorgyi, Nobel Laureate in Medicine and Physiology