Audit a Perl 5.14 Upgrade with Reproducible Checks

You will turn perl5140delta into a short upgrade audit: record the interpreter you are testing, exercise the Unicode and regular-expression changes that can alter results, and search for syntax and deprecation traps. Allow 20 to 30 minutes for a small application, plus time to run its own tests.

This guide treats Perl 5.14.0 as the subject, not as the version installed here. The local perl-doc package is 5.38.2-3.2ubuntu0.6, and the local interpreter is Perl 5.38.2. That is useful for checking the examples, but it cannot reproduce every warning or compatibility edge case from an actual 5.14 binary. The delta document describes changes from Perl 5.12.0 to 5.14.0. If your starting point is older than 5.12, read the intervening delta documents as well.

1. Record the interpreter and read the delta document

Start by capturing the version that will run your tests:

$ perl -e 'print $^V, "\n"'
v5.38.2
$ perldoc perl5140delta

The second command opens the installed copy of the document. Its NAME and DESCRIPTION sections state the comparison range. The manual is a change list, not a migration script, so keep your application test suite beside it.

Checkpoint: write down the old interpreter, the candidate interpreter, and the package versions that supplied both. A version label such as "Perl 5" is not enough when behaviour and bundled modules matter.

2. Make Unicode intent explicit

Perl 5.14 completed the unicode_strings feature and added Unicode 6.0 data, with documented exceptions. The practical question is not whether a program can store a non-ASCII character. It is which semantics its string operations and regular expressions are meant to use.

Run a focused comparison with an accented character:

$ perl -e 'print "no match\n" unless "é" =~ /\w/a; print "ascii restriction checked\n"'
ascii restriction checked
$ perl -Mfeature=unicode_strings -e 'print "unicode match\n" if "é" =~ /\w/'
unicode match

The /a modifier keeps \w, \d, \s and POSIX character classes in the ASCII range while retaining Unicode case behaviour. The /u modifier requests Unicode semantics for a pattern. Do not add either modifier mechanically: choose it where the input contract requires it, then add a test for an actual boundary character.

Review named characters too. Perl 5.14 changed the handling of names around BELL; use \N{BEL}, \N{ALERT} or \a when you mean U+0007 rather than relying on the transitional spelling. This is a source review task, not a reason to alter generated Unicode data files. The 5.14 manual says those database files were no longer installed with Perl, without removing the runtime functionality.

3. Check regular expressions for changed assumptions

Perl 5.14 added the /d, /l, /u and /a regular-expression modifiers. It also changed the string form of compiled expressions. Code that compares a regex string to a fixed value can therefore break even when matching itself is correct.

$ perl -we 'my $re = qr/foo/i; print "$re\n"'
(?^i:foo)

Search tests, loggers and serialisers for comparisons against the old (?i-xsm:...) style. If the program needs the pattern and modifiers separately, use the documented re interface rather than parsing this display form.

The release also introduced non-destructive substitution and transliteration with /r. It returns a changed copy and leaves the source alone:

$ perl -we 'my $old = "cat"; my $new = $old =~ s/cat/dog/r; print "$old/$new\n"'
cat/dog

This is a safe refactoring where old code makes a copy only to avoid modifying its input. Keep the original test that proves the input remains unchanged. Treat regex code blocks such as (?{...}) as a separate risk: the manual calls them experimental even though re-entrant use became safer.

4. Search for source and deprecation traps

Run searches over the source tree before changing code. These patterns target documented 5.14 compatibility points:

$ rg -n 'for\s+\$\w+\s+qw\(|\$\[|\bBELL\b|\?[^?]+\?|defined\s+%[A-Za-z_]' lib bin t

Give every match a human decision. Perl 5.14 stopped accepting some uses of qw(...) as if it supplied parentheses, and assignments to $[ were deprecated. The old ?PATTERN? search form changed from a once-only search to a resettable form. A defined %Package:: test is not an emptiness test; use scalar hash behaviour instead.

Do not use a broad search-and-replace for these findings. A literal string, a comment, and executable Perl need different treatment. Run the application's tests after each small batch.

5. Check modules and binary boundaries

The delta document lists new and updated core modules, including HTTP::Tiny, JSON::PP and CPAN::Meta. Compare your dependency manifest with what the target package actually provides. A module being core in one Perl release does not prove that a separately packaged operating-system build supplies the same version.

Also flag XS modules and embedded interpreters. Perl 5.14 was not binary-compatible with previous stable releases, so rebuild native extensions and rerun their tests against the target interpreter. This is the point at which elevated privileges may be needed to install a system package, but the audit commands above should remain unprivileged. Do not replace the system Perl merely to test an application; use an isolated build or the distribution's supported packaging method.

6. Finish with a controlled test run

Run the project's normal checks with warnings enabled where the project permits it:

$ prove -lr t
$ perl -c bin/example.pl
bin/example.pl syntax OK

If a test fails, retain the failing input and the interpreter version before editing. That makes a Unicode boundary, regex stringification change or deprecation warning reproducible. Recovery is normally a code or dependency rollback: do not suppress a warning globally until you know which compatibility issue it represents.