David Golden wrote:
> RECOMMENDATION FOR A VERSION NUMBER STANDARD
>
> A "Version Number" may be expressed in one of two forms:
>
> (a) A tuple of at least three integers, prefixed with a leading "v".
> Tuples may be separated by either periods (".") or underscores ("_").
> Examples: "v1.2.3", "v3.14.0", "v1.2.3.4", "v1.2.3_4".
This would be OK except that the original bug report was Debian's packaging tool
being unable/unwilling to cope with version's with leading 'v' (which we can
actually claim is Debian's problem).
> (b) A non-negative decimal number. The number may contain one or more
> underscores as per the rules for numeric literals.
With a) and b) together (along with the comparisons below), you've described
version.pm's behavior in a nutshell (but only a single underscore, please).
Except for one tiny little problem:
$ perl -Mversion -e 'print version->new("1.2.3");'
1.2.3
$ perl -Mversion -e 'print version->new("v1.2.3");'
v1.2.3
Before version.pm was added to the core, the discussion on p5p went in the
direction of "always stringify to the same form that the author originally
typed" rather than the ->normal form with a leading 'v' (which is how I had it
originally). Consequently, that is how it works in Perl 5.10.0 (and at least
until 5.12.0 for a full deprecation cycle).
Now, META.yml could define something different for how _it_ stores version
numbers, but I can't see how that is going to be any less confusing...
> For version comparison, Version Numbers of type (b) are converted to
> type (a) by removing underscores and converting according to the
> 3-digit Perl version number convention. Example: "1.02" is 1.020 and
> becomes "v1.20.0", "1.02_03" is 1.020300 and becomes "v1.20.300".
That is an internal implementation detail and should not be exposed (i.e. don't
save the converted version). It would be just wrong to downgrade extended
versions to numeric or upgrade numeric to extended; it is not what the author
typed and will be Surprising.
> Modules that are changing from type (b) to type (a) must convert the
> current version number according to the convention described above
> before incrementing a component of the tuple.
This is impossible to require, though we can certainly recommend it. If PAUSE
doesn't already mandate new releases having a version.pm-mediated comparison
greater than the current latest release, then we should certainly ask Andreas to
do so. Someone with more tuits than I should also scan the current CPAN
listing to find more lurking horrors like Text::Autoformat's problem.
> Any version that does not appear in the form of type (a) or type (b)
> is considered invalid. The behavior of modules encountering invalid
> versions is undefined.
And is this enforced by Module::Build or whatever tool is used to generate
META.yml? This won't stop someone from manually mucking with META.yml, but we
can't help that. All that we can hope to do is make it easy to do it right, and
hard to do it wrong. This is the nature of defensive coding... ;-)
John
