Skip navigation

(The lowercase “p” perl is what I mean in the title.)

There’s a great new page on the Perl 5 wiki about administering your perl installation. It includes quite a number of things I believe in. Some of the more significant bits:

First and foremost thing I can say is if you depend heavily on Perl (or any single piece of technology) build it yourself. This will allow you finer control and faster upgrades than your OS vendor can. Windows is the exception, Strawberry Perl does a much better job packaging Perl and tweaking it for Windows than you can (and if you think you can better, please contribute to Strawberry).

This is especially true on Red Hat. Ignoring general management issues, you really ought to have a threaded and a non-threaded perl so that single-threaded code doesn’t pay the overhead for threads.

Fourth, keep up to date. This means keeping CPAN modules and perl itself at or near the latest versions. This will incur the occasional breakage as you encounter either intermittent bugs in new versions of CPAN modules, or API changes, or project code that accidentally depends on certain versions of CPAN modules. But it’s worth it, because the farther you fall behind the harder it becomes to catch up. As your perl gets older and older, fewer and fewer CPAN modules will work requiring more and more patching to get them working. As your CPAN modules get older, it will require a greater leap to bring them up to date, and more upgrades simultaneously. The sudden upgrade will cause many bugs to happen simultaneously making them take far more time and effort to track down then if they could be dealt with individually. Large upgrades require large effort, time and risks. Small upgrades require small effort, time and risks. The looming risk of a large upgrade will make developers settle for an older, buggier, less capable version and write a work around rather than risk the upgrade. This creates a hidden drag on your project and creates more and more complex code to maintain.

Another point: when you discover a bug in a CPAN module, there may be a fix for it, but if you’re very out of date with it, it may cause significant problems with other modules, making your upgrade of that one module really painful.

At Barclay’s, it took me 7 months to upgrade them from perl 5.6 to 5.8 and the latest version of other modules. Way too long.

If you’ve got good test coverage, you should be able to easily find any problems with upgrades.

%d bloggers like this: