Use perl5122delta to Check a Perl 5.12.2 Upgrade

You will finish with a small, evidence-based checklist for assessing the move from Perl 5.12.1 to 5.12.2. perl5122delta is a release note, not an upgrade command: it tells you what changed, then you verify the parts your program actually uses. The installed documentation comes from the perl-doc package, version 5.38.2-3.2ubuntu0.6, while the document itself describes the historical 5.12.2 release.

Allow about 20 minutes for the checklist, plus the time needed to run your application's normal tests. You need a shell, a Perl installation, and a copy of the application's test command. Nothing below needs elevated privileges. Do not run these checks against production data if your test suite writes files or sends messages.

1. Establish the release boundary

Start by recording the interpreter and the documentation package. This prevents a common distraction: reading a 5.12.2 delta 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 may differ. The important facts are the exact Perl version and whether the local perl5122delta page is installed. If dpkg-query is unavailable, use rpm -q perl-doc on an RPM-based system or omit the package query. The release note remains a historical document either way.

2. Read the delta for changes that can affect your code

Open the local page, then concentrate on the sections headed "Incompatible Changes", "Pragmata Changes", "Updated Modules", "Utility Changes" and "Selected Bug Fixes". The local page says there are no intentional incompatibilities with 5.12.1 and no new modules or pragmata in 5.12.2. That is useful context, but it is not a promise that every application behaves identically after an upgrade.

$ man perl5122delta
$ perldoc perl5122delta

For a searchable text copy without changing the installed documentation, use:

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

Do not treat every listed fix as an action item. The page includes portability fixes for VMS, compiler and cross-compiler fixes, and memory-safety fixes that may not be observable in an ordinary Linux application. Mark a change as relevant only when your code, dependencies, build process, or supported platform reaches it.

3. Capture the module versions your application uses

The release 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 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

Again, these are examples 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 inferring it from the version number alone.

For a larger dependency set, run the application's existing dependency report, such as its lockfile or deployment manifest. Do not install modules merely to reproduce this historical release note.

4. Test the pragmata and utility paths you rely on

The documented pragma change concerns a previous bug involving no VERSION;, which could load feature bundles and enable strict mode unexpectedly. Make a focused test for code that uses versioned pragmata, and keep it 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 command checks the interpreter's version requirement. The second only exercises the syntax path; it does not prove that an old interpreter had no bug, nor does it replace the application's tests. If your program uses caller(), custom @DB::args handling, XS modules, unpack(), Unicode regular expressions, or File::Glob, add a small regression test that reaches the relevant code. The release note specifically records fixes for those areas, including crashes and memory leaks.

For perlbug, the page records fixes to address guessing the reporter's email address and warnings with -d and -v. Those are diagnostic-tool changes, not application interfaces. Test them only if you maintain a Perl development workflow that depends on this utility.

5. Run the real test suite and compare failures

Run the application's normal tests with a clean environment. Use a temporary checkout or disposable test database when the suite changes state. This step may take longer than the guide and may need project-specific credentials, services, or containers.

$ 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 are illustrative: accept the output produced by your project. Save the complete result with the interpreter version and module report. If tests fail, first confirm that the same Perl executable and dependency set were used on both runs. Then map the failure to a section of perl5122delta. A change listed in the document is a lead for investigation, 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 sensible 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 using the package manager transaction, previous image tag, or release artefact used by your organisation. Do not remove a system Perl manually: Linux tools may depend on it. The commands in this guide make no persistent changes, so there is nothing to undo here.