Safety in (Version) Numbers


If you believe what I wrote in The "Guess the Version" Game, there's no completely reliable way to determine the appropriate version of the Perl 5 language which applies to a given file. You can use a static analysis tool such as Perl::MinimumVersion to give you a best guess based on a set of heuristics... but that's possible to fool.

Unlike Perl 5 static parsing, where only a malicious developer would write the maintenance-nightmare code that foils a smart static analysis tool, it's reasonably easy to imagine that a well-meaning and maintenance-savvy developer might write code that fools the language version checker. After all, keywords like class and say and err make a lot of sense as keywords because they describe concepts effectively and efficiently. There's little difference between choosing good keywords and good symbols for identifiers.

There's only one good way to specify the intended version of the Perl 5 language in use in any given source code:

package SecretMonkey::Utilities;

use 5.010;


If you want to future-proof your code against future language changes, document your assumptions. (Note that well-packaged CPAN distributions have had this policy for years. It's not a new idea; it's a good idea unevenly distributed.)

If Perl 5 had adopted this policy a decade ago (or, better, even earlier!), we could avoid a lot of current problems with the debate between making new features available by default or being as compatible with Perl 5.000 as possible by default. perl can't assume anything about the features used or not used within a particular file -- especially new keywords -- because it doesn't know which version of the language to use to parse the code.

Any new Perl 5 code written after this point which lacks a language version specifier in every file carries a very preventable maintenance risk. You don't have to use Perl 5.10.x (though you should), but you should specify the version of the language you expect.


I write everything using (5.10.1), and I don't keep any older versions around. I don't think I use any particularly esoteric features; I suspect my code works fine in 5.8 and maybe even earlier. Without installing a bunch of older Perls to test though, I can't be sure. It feels wrong to write "use 5.010" at the top when I know that's probably a lie, but it also feels wrong to write nothing at all. Do you have a particular recommendation for this scenario?

I guess it depends on your intentions, especially your intended audience for the code. You could write "use 5.008", meaning "I intend this code to work on 5.8, if it doesn't (e.g. if I use a 5.10-only feature), that's a bug". Or you could write "use 5.010", meaning "I intend this code to work on 5.10; it's possible it works on 5.8, but I don't really care one way or the other."

Assume someone wants to use your code with 5.8. In the first case ("use 5.008"), they'll initially be happy, try your code, and if it doesn't work, they'll curse your name, then either fix the code to run under 5.8, or give up and try some other code. In the 2nd case ("use 5.010"), they'll start out a little less happy. They'll either give up and try something else, decide to try to back-port your code to 5.8, or be motivated to upgrade to 5.10.

Personally, if I needed to use your code, there were strong reasons I couldn't upgrade to 5.10, and there wasn't an equally-good 5.8-compatible module as an alternative, I'd probably try changing your code to "use 5.8" and see if the unit tests pass.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with Modern Perl Whitepapers



About this Entry

This page contains a single entry by chromatic published on December 16, 2009 4:29 PM.

The "Guess the Version" Game was the previous entry in this blog.

Helping Perl Packagers Package Perl is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?