NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Same problems as 5.6 (Score:2)
When 5.6.x came out, some people put:
in their Makefiles/module, again often for no reason. I think that the "our" keyword was often the only valid reason why they specified 5.6.x, and that's often avoidable.I know my modules have only been tested with a limited subset of Perl versions, I say
use 5.006;because I do use "our" and I don't have any older Perls to test it with. I think things have moved on enough for me to say this, but accept patches, whereasuse 5.008;by default seems a little premature.-- "It's not magic, it's work..."
Reply to This
Re:Same problems as 5.6 (Score:1)
Re:Same problems as 5.6 (Score:2)
IMO it would have been nicer if there was a commandline option that allowed you to specify a specific version, rather than always assuming the current version onwards. I haven't used h2xs in a very long time, so never realised it did that.
Oh well, at least I know why now.
Re:Same problems as 5.6 (Score:2)
I would sooner remove the version line and wait for cpan-testers to notify if it fails on a particular version or platform.
I try not to use non perl 5.5 syntax in any CPAN code. Writing for CPAN is different to writing work projects where you know what modules will be installed and which version.
This is why releasing work code to CPAN is nontrivial - first you have to check its not going to lose your employer (or yourself) competitive advantage, the
@JAPH = qw(Hacker Perl Another Just);
print reverse @JAPH;