Check a Perl 5.20.3 Upgrade Without Guessing

perl5203delta already tells you exactly which regular expressions used to misbehave, so there is no reason to find out the hard way in production. This guide turns it into a short, evidence-based checklist for deciding whether a Perl 5.20.3 upgrade needs extra testing on your Linux system: separate interpreter changes from module updates, then turn the relevant bug fixes into small smoke tests. The document describes the change from Perl 5.20.2 to 5.20.3, not a general guide to whatever Perl is installed today.

Allow 20 to 30 minutes for a small application, longer if it uses XS modules, taint mode, threads, unusual regular expressions or UTF-8 identifiers. You need a shell, the installed Perl documentation package, and a copy of the application or test suite. The commands below only inspect files or run short Perl processes, and no elevated privileges are required.

1. Record the Perl you are testing

Start by recording the interpreter and the relevant documentation package. This heads off a common distraction: reading a historical delta document and assuming it describes whichever interpreter happens to be first in your PATH.

$ perl -v
$ perl -V | sed -n '1,12p'
$ man perl5203delta

The installed manpage on this system is generated for Perl 5.38.2, while its subject is the historical 5.20.2 to 5.20.3 release. Your first command should tell you which binary your application will actually run. If man perl5203delta comes back empty, install the documentation package your distribution provides, usually named perl-doc, then repeat the command.

2. Read the delta by impact, not from top to bottom

Read the sections in this order: Selected Bug Fixes, Modules and Pragmata, Platform Support, then Documentation. The release has no changes intentionally incompatible with 5.20.2, but that does not make every application risk-free: a crash fix or a change in regular-expression behaviour can alter a program that was quietly relying on a bug.

Mark a fix as relevant when your code touches one of these areas:

• large tainted strings with repeated global matches, where an old performance problem could edge into a denial-of-service concern;
• UTF-8 variable names, function names, here-document terminators or regular expressions;
• possessive quantifiers with equal minimum and maximum bounds;
• threads that clone an array and then extend it;
• the special variable $/, warning fatality, setpgrp, or parsing around an unfinished bracket expression;
• XS builds, h2ph, or 64-bit Visual C++ builds on Windows.

Don't turn a single entry into a promise about every later Perl release. The h2ph note, for instance, is specifically about hexadecimal constants in GCC's predefined macros, and the Win32 notes concern compiler and architecture combinations that simply do not apply to ordinary Linux builds.

3. Check the regular-expression regression you actually use

The 5.20.3 notes say a possessive quantifier such as a{3,3}+ should behave like an equivalent atomic group, and that Perl 5.20 had a regression when the two bounds were equal. Run both forms against a small string:

$ perl -e 'print "possessive\n" if "aaa" =~ /a{3,3}+/; print "atomic\n" if "aaa" =~ /(?>a{3,3})/;'
possessive
atomic

This confirms syntax and result, nothing more; it is not proof that your production expressions are safe. Copy the actual expressions from your test suite into isolated tests and compare captures, backtracking behaviour and runtime before and after an interpreter change. Do not stop at a short successful input either: the delta specifically calls out long strings and patterns beginning with a greedy wildcard as a performance area.

4. Add focused tests for data and parser edge cases

Several fixes are easier to cover with a regression test than a one-line demonstration. Keep each test small enough that a failure points at a single language feature. This one checks that a failed assignment to $/ does not silently leave the visible value looking valid:

use strict;
use warnings;

local $/ = "\n";
my $before = $/;
my $error = eval { $/ = []; 1 };
die "assignment unexpectedly succeeded\n" if $error;
die "record separator changed\n" if $/ ne $before;
print "record separator preserved\n";

The exact warning and exception text is not a stable interface, so test the state your program actually depends on rather than matching diagnostic wording. Add separate tests for UTF-8 names and here-documents if your source uses them, keep the source file UTF-8 encoded, and run it with the same command line and environment as the application.

Do not use malformed code copied from the delta as a production probe. The note about an expression such as /$a[/ describes a parser bug that could read another input line or crash older Perl versions. Keep parser regressions in a disposable test file under your test suite, and never feed untrusted text to an evaluator merely to see how it parses.

5. Check module and build-sensitive changes

Compare the versions named in the document with the interpreter you will deploy. Perl 5.20.3 updated Errno, Module::CoreList and perl5db.pl. Where a system provides those modules, inspect the versions without changing anything:

$ perl -MErrno -e 'print "Errno $Errno::VERSION\n"'
$ perl -MModule::CoreList -e 'print "Module::CoreList $Module::CoreList::VERSION\n"'
$ perl -V:version

These commands only report the modules belonging to the selected interpreter. They prove nothing about a separately installed CPAN copy, an application bundle or a container image using the same files, so run the application's dependency and test commands in the deployment environment as well.

Building XS code or regenerating header wrappers? Record the compiler and architecture. The 5.20.3 notes mention GCC 5 preprocessor line directives, hexadecimal compiler macros seen by $Config{cppsymbols}, and a 64-bit Visual C++ warning problem. These are build checks, not licence to change Linux compiler flags on a hunch.

6. Decide, document and recover

Keep the delta document, perl -V output, focused test results and application test report together. Record the interpreter path with command -v perl, since a successful shell test can still use a different Perl from the one the service manager or deployment image actually runs.

If the new interpreter fails a test, do not paper over it by changing production code first. Re-run the test with the old and new interpreters, reduce it to the smallest input, and check whether the result is an expected correction of old behaviour. Roll back by restoring the previously tested Perl package or deployment image through your package manager's normal change process; that rollback changes system state and may need elevated privileges, so take a package snapshot or deployment revision before upgrading and follow your local recovery procedure.

Report a suspected core defect with a minimal reproducer and the output of perl -V, leaving out credentials, customer data or proprietary source. For a security-sensitive Perl core issue, use the private reporting route the Perl project documents rather than posting exploitable details publicly.