> I had wondered whether eval might also cater for version strings that contain multiple decimal points (v-strings),
The last part of dagolden's summary recommends to avoid dotted-integer versions
Given these criteria, my recommendation is to use decimal version numbers, put them in quotes, and add a string eval:
our $VERSION = "0.001";
$VERSION = eval $VERSION;
This is safe and effective and always works. By putting any $VERSION in quotes, even if it isn’t an alpha, you don’t have to remember to add them if you ever change to an alpha version. (And numbers with trailing zeroes are nicely formatted when parsed for distribution versions.)
If you really want to have a dotted-integer module version, then I strongly recommend that you limit your module to Perl 5.10 (or require version.pm and at least Perl 5.8.1) and that you never use an alpha version number. Always quote your dotted integer version when you define it and always use a leading-v to guide your users towards proper usage.
It’s unfortunate that version numbers are so complicated in Perl, but if you follow the recommendations in this article, your version numbers will be as boring as possible. And if you’ve read this all the way to the end, I hope I’ve convinced you that ‘boring’ version numbers are exactly what you want.
| [reply] |
our $VERSION = "0.001"; $VERSION = eval $VERSION;
The thing I don't like about this is that (depending upon the original string), you might find that, after the eval is done, "$VERSION" ne <original_string>
No such problem with "0.001", but consider this simple script:
use strict;
use warnings;
my $str = "2.30";
our $VERSION = $str;
$VERSION = eval $VERSION;
print "WTF\n" if $VERSION ne $str;
That outputs "WTF".
That is, having assigned the string "2.30" to $VERSION, the eval forces $VERSION into a state where it stringifies to something other than "2.30" - namely to "2.3".
It's probably of little importance, but I found it annoying enough to immediately replace all occurrences of eval $VERSION in my .pm files with #eval $VERSION
I've no regrets about having done that, yet.
Notably, with the eval removed, we can then perform both numeric and string comparisons reliably:
use strict;
use warnings;
my $str = "2.30";
our $VERSION = $str;
print "OK 1\n" if $VERSION == 2.3;
print "OK 2\n" if $VERSION == $str;
print "OK 3\n" if $VERSION eq $str;
print $VERSION, " ", $str, "\n";
print "$VERSION $str\n";
__END_
outputs:
OK 1
OK 2
OK 3
2.30 2.30
2.30 2.30
I find that saner and preferable ... though I now always avoid using version strings that terminate with one or more zeros ... just in case ;-)
Cheers,
Rob
| [reply]
[d/l]
[select] |
The generally recommended practice now is to use $VERSION =~ tr/_//d; rather than $VERSION = eval $VERSION. This removes the underscores, but leaves trailing zeros intact. This also only applies if you are using numeric versions (rather than three part versions like v1.2.3) and are using underscores to denote developer releases. Using -TRIAL releases is another option that many prefer rather than using underscores.
| [reply]
[d/l]
[select] |
Hi
2 things
- make-maker and other tools are statically parsing perl files for $VERSION = "numberwang" so your example with $str won't work.
- the comparison is supposed to be numeric, it's no surprise that string comparison will often fail on numbers! Just try sort 8..12 to see what I mean. °
I'm afraid make-maker is keeping us stuck with $VERSION syntax for backwards compatibility.
see also davido's research: Re: Why eval $version?
But I could imagine a module Version::Smart exporting a tied object in $VERSION which DWIM.
Though I'm wary of XKCD's standards ...
Update
°) yes I know, since it's quoted it looks like a string
| [reply]
[d/l]
[select] |
I read dagolden's article thrice and my head keeps smoking because of the confusion.
| [reply]
[d/l]
[select] |
