Use perl5320delta to Check Perl 5.32 Compatibility

You will turn perl5320delta into a short compatibility check for a Perl upgrade, then run safe probes for the changes most likely to affect source code. Allow about 20 minutes for a small application, longer if it uses custom regular expressions or bundled modules. You need a shell, the perl-doc package, and a copy of the application or test suite you intend to review.

The installed manual is release-specific. On this machine it comes from perl-doc version 5.38.2-3.2ubuntu0.6, while the interpreter is Perl 5.38.2. The document itself describes the differences from Perl 5.30.0 to Perl 5.32.0. It is a change list, not a migration tool: it will not inspect your source, select an interpreter, or update a package.

1. Confirm the installed interpreter and manual

Start with read-only version checks. Ordinary users can run these; elevated privileges are not needed:

$ command -v perl
/usr/bin/perl
$ perl -e 'print "$^V\n"'
v5.38.2
$ dpkg-query -W -f='${Package} ${Version}\n' perl-doc
perl-doc 5.38.2-3.2ubuntu0.6
$ man -P cat perl5320delta | sed -n '1,18p'
PERL5320DELTA(1)       Perl Programmers Reference Guide       PERL5320DELTA(1)

NAME
       perl5320delta - what is new for perl v5.32.0

Checkpoint: record the Perl version that runs your application, not just the version printed by a documentation package. If man cannot find the page, install perl-doc through your normal package-management process, then repeat the check. Do not use sudo merely to read a manual or run the probes below.

2. Read the change list in upgrade order

Read the description first. It says which two releases are being compared and points to perl5300delta when you are coming from an older release. Then concentrate on the headings that can change program behaviour:

$ man perl5320delta
$ man perl5300delta
$ man perlop
$ man perlre

In perl5320delta, begin with Incompatible Changes, then read Security, Core Enhancements, and Modules and Pragmata. Treat Performance Enhancements as useful context, not as a reason to change code without a measurement. The manual lists three regular-expression memory-safety issues and says an application is exposed when it evaluates attacker-supplied patterns. That is a boundary for your threat review, not an invitation to paste hostile patterns into a production process.

For a source review, search the application for the constructs named in the incompatible-changes section: vec on Unicode strings, string bitwise operators, Sys::Hostname::hostname with an argument, user-defined Unicode properties, \K inside look-around assertions, and code that depends on the old "0" .. "-1" range behaviour.

3. Probe the new syntax in isolation

Run a tiny temporary command before changing application code. The isa operator is documented as experimental in 5.32, so enable its feature explicitly when testing code that targets that release:

$ perl -e 'use feature "isa"; package Widget; sub new { bless {}, shift }; my $obj = Widget->new; print($obj isa Widget ? "isa-ok\n" : "isa-no\n")'
isa-ok

A common distraction is testing the syntax without the feature declaration on an interpreter that has not enabled it automatically. The perlop documentation says use v5.36 or newer enables it automatically, but code intended to run on 5.32 should make its feature choice visible.

Chained comparisons are another 5.32 change. The middle value is evaluated once in the simple case, and the expression is equivalent to two comparisons joined by &&:

$ perl -e 'my ($x, $y, $z) = (1, 2, 3); print(($x < $y <= $z) ? "chain-ok\n" : "chain-no\n")'
chain-ok

Keep the expression simple while migrating. The release note qualifies the equivalence for a simple middle scalar, so do not assume that a function call or side effect in the middle behaves like a repeated hand-written expression.

4. Check Unicode and range assumptions

The release notes add Unicode 13.0 support and make the Unicode Name property available in regular expressions. A harmless local probe confirms that the installed interpreter accepts the documented form:

$ perl -CS -e 'print("name-ok\n") if "A" =~ /\p{Name=LATIN CAPITAL LETTER A}/'
name-ok

This verifies syntax and a match on the current interpreter. It does not prove that a security-sensitive identifier policy is correct. If your program validates names, read the Unicode and application-level rules together and test accepted and rejected input from a fixture file.

The plain string "0" is a notable compatibility trap. In 5.32, the range operator treats it as a number, so the old surprising string range no longer produces values through "99":

$ perl -e 'my @range = ("0" .. "-1"); print scalar(@range), "\n"'
0
$ perl -e 'print join("|", ("0" .. "9")), "\n"'
0|1|2|3|4|5|6|7|8|9

Search for ranges built from strings before relying on a test that only checks the common positive case. If the application needs padded values such as 00 through 03, make that intent explicit and test the exact output.

5. Run the application tests under the target Perl

After the focused probes, run the project's normal test command with the interpreter you plan to deploy. This is where release-note findings become evidence about your code:

$ perl -Ilib -MExtUtils::MakeMaker -e 'print "perl=$^V\n"'
perl=v5.38.2
$ prove -l t
# project-specific test output appears here

Replace the test command with the project's documented command. Do not claim compatibility from a successful version probe alone. A passing suite on Perl 5.38.2 also does not prove support for every older 5.32 patch release, so record the tested interpreter and keep the release-note review in the change record.

If a test fails, first map it to a named section in perl5320delta. Reduce the failure to a small test case, then compare the old and new interpreter results in separate, deliberately selected environments. Do not replace a failing security or correctness test with a looser assertion just to make the upgrade green.

6. Keep the review reversible

The commands in this guide read documentation or run in-memory Perl snippets. They do not edit a service, install a module, or change system configuration, so there is nothing to undo. If you are testing an application checkout, keep the release-note edits and dependency changes in version control and make a small commit before altering more than one compatibility issue at a time.

Do not run perlthanks from an unattended server: the manual documents it as a program that sends email to the Perl developers. Do not test crafted regular expressions against a production service either. Use a disposable process with resource limits and a fixture designed for your security test, or rely on the project's maintained regression tests.