Use perl5122delta to Check a Perl 5.12.2 Upgrade

perl5122delta reads like a changelog, but it is really a pre-flight checklist for the jump from Perl 5.12.1 to 5.12.2. It will not upgrade anything itself: it tells you what changed, and you decide what to test.

Allow about 20 minutes for the checklist, plus whatever time your application's own tests need. The installed documentation comes from the perl-doc package, version 5.38.2-3.2ubuntu0.6, while the page itself describes the historical 5.12.2 release, not the Perl running on this machine.

• You need: a shell, a Perl installation, and the application's normal test command.
• Nothing here needs root. Skip running the checklist's test suite against production data if it writes files or sends messages.

1. Establish the release boundary

Record the interpreter and the documentation package before you read a word of the delta. This stops a common mix-up: reading a 5.12.2 note and assuming it describes every later Perl release.

$ 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

Your output will differ. What matters is the exact Perl version and whether perl5122delta is installed locally. No dpkg-query? Try rpm -q perl-doc on an RPM-based system, or skip the package query; the release note is historical either way.

2. Read the delta for changes that touch your code

Open the local page and go straight to the sections that matter for compatibility:

• Incompatible Changes. The page reports none against 5.12.1.
• Pragmata Changes. None new in 5.12.2 either.
• Updated Modules, Utility Changes, Selected Bug Fixes. This is where the real content lives.

"No intentional incompatibilities" is useful context, not a promise that your application behaves identically after the upgrade.

$ man perl5122delta
$ perldoc perl5122delta

Want a searchable text copy without touching the installed documentation?

$ zcat /usr/share/man/man1/perl5122delta.1.gz | less

Do not treat every listed fix as an action item. The page carries portability fixes for VMS, compiler and cross-compiler fixes, and memory-safety fixes that may never surface in an ordinary Linux application. Flag a change only when your code, dependencies, build process, or platform actually reaches it.

3. Capture the module versions your application uses

The notes call out Carp and File::Spec upgrades, plus fixes in CPANPLUS, File::Glob and File::Copy. Record the versions in the interpreter that will actually run the application:

$ perl -MCarp -e 'print "Carp $Carp::VERSION\n"'
Carp 1.54
$ perl -MFile::Spec -e 'print "File::Spec $File::Spec::VERSION\n"'
File::Spec 3.88
$ perl -MFile::Copy -e 'print "File::Copy $File::Copy::VERSION\n"'
File::Copy 2.41

Those numbers are from the current machine, not the 5.12.2 values. The delta records Carp moving from 1.16 to 1.17 and File::Spec from 3.31 to 3.31_01. If an application depends on a module's exact behaviour, put that dependency in its test matrix rather than guessing from a version number.

For a bigger dependency set, run the application's own dependency report, its lockfile or deployment manifest. Do not install modules purely to reproduce a nine-year-old release note.

4. Test the pragmata and utility paths you rely on

The documented pragma fix concerns a bug in no VERSION;, which could load feature bundles and switch on strict mode unexpectedly. Run a focused test in the same environment as the application:

$ perl -e 'use 5.12.2; print "version requirement accepted\n"'
version requirement accepted
$ perl -we 'no 5.12.2; print "pragma path exercised\n"'
pragma path exercised

The first line checks the interpreter's version requirement. The second only exercises the syntax path; it does not prove an old interpreter was bug-free, and it does not replace your own tests. Add a small regression test if your program touches any of these:

• caller() or custom @DB::args handling.
• XS modules.
• unpack().
• Unicode regular expressions.
• File::Glob.

The release note specifically records fixes in these areas, including crashes and memory leaks.

For perlbug, the page notes fixes to guessing the reporter's email address and to warnings under -d and -v. Those are diagnostic-tool changes, not application interfaces: test them only if your own workflow depends on this utility.

5. Run the real test suite and compare failures

Run the application's normal tests in a clean environment. Use a temporary checkout or disposable test database if the suite changes state; this step can take longer than the rest of the guide combined and may need project-specific credentials or services.

$ prove -lr t
All tests successful.
Files=12, Tests=184,  3 wallclock secs ( 0.08 usr  0.02 sys +  1.10 cusr  0.16 csys =  1.36 CPU)
Result: PASS

The counts above are illustrative; accept whatever your project produces. Save the full result alongside the interpreter version and module report. If tests fail, first confirm both runs used the same Perl executable and dependency set, then map the failure to a section of perl5122delta. A change listed in the document is a lead, not proof of causation.

6. Record the decision and the rollback

Keep the release note, version output, dependency report and test result together with the upgrade review. A sound decision has three parts: which 5.12.2 entries apply, which tests cover them, and what evidence supports deployment.

If the deployment changes an interpreter package or image, roll back through the package manager transaction, previous image tag, or release artefact your organisation uses. Do not remove a system Perl by hand; other Linux tools may depend on it. Nothing in this guide makes a persistent change, so there is nothing to undo here.