Upgrading Perl codebase of older Perl version

[programmingzeal]

Hi, I intend to upgrade a Perl codebase which is written in Perl 5.16.3 version for Linux platform. What most important things and factors have to be considered while upgrading it to Perl version 5.40.0? I mean the legacy code should be upgraded with original logic intact. The Perl codes base is about database integration of ecommerce website and is to be hosted on AWS server live. Are there any major differences in Perl syntax of older version?

[ikegami]

Go to see perl. Scroll down to the History section. Looks at the Incompatible Changes section of the perldelta documents for .0 versions.

• Perl 5.18's incompatible changes
• Perl 5.20's incompatible changes
• Perl 5.22's incompatible changes
• Perl 5.24's incompatible changes
• Perl 5.26's incompatible changes
• Perl 5.28's incompatible changes
• Perl 5.30's incompatible changes
• Perl 5.32's incompatible changes
• Perl 5.34 has no incompatible changes
• Perl 5.36's incompatible changes
• Perl 5.38's incompatible changes
• Perl 5.40's incompatible changes

[NERDVANA]

There are two major changes that affected many projects, both done for security:
1. 5.18 introduced more-randomized hashes. This shouldn't break any code, but some code only worked by chance of which order the hash keys landed normally, and will be broken now that they iterate in a different order on every run.
2. 5.24 removed the current directory "." from the @INC include path. This breaks any project that used use MyModule; to mean require "./MyModule.pm";. You can still add the current directory back to @INC manually, but it's much better to organize the module directories and declare them all in perl -I ... or PERLLIB at startup.
Most of the rest tends to be stuff related to deprecating/removing old features from perl 4 or early versions of 5, or experimental features. If your Perl 5.16 code was written in a "normal" style, none of this should affect you.

[cavac]

BEGIN {
    unshift @INC, "/some/path/Net-Clacks/lib";
    unshift @INC, "/another/path/My-Secret-Module/lib";
};
use Net::Clacks;
use My::Secret::Module;

At least that's the variant i use when debugging. (Original code checks for the '--debug' flag and only unshifts the uninstalled paths if that is set).

[NERDVANA]

That works too. I prefer more like

#! /bin/sh
exec perl -I /some/path/Net-Clacks/lib -I /another/path/My-Secret-Modu
+le/lib myapp.pl "$@"

in a file named debug_myapp.pl, which helps keep my temporary local debugging stuff out of the committed code of the project.

[LanX]

Perl is usually very backwards compatible - some say too much - and very outspoken in reporting changes and deprecations.

Changes mostly affect exotic features or unsuccessful feature experiments.

I'd say the best strategy is to use perlbrew and install various versions to run your code. Check the logs for errors and warnings.

And try establishing automated tests to assure that your application "works" as intended.

You can either gradually increment the version, or just do a binary version search till it breaks.

My intuition tells me that you'll rather have problems with CPAN modules in your dependency chain or third party components of your application. (I once had an application which suffered from a subtle break after MySQL was upgraded)

But that mostly depends on the quality of your code.