Review a Perl 5.8.8 Upgrade with perl588delta

perl588delta will not change your Perl or run an upgrade for you. Read properly, it turns a 5.8.7 to 5.8.8 move into a short, evidence-based checklist, keeping the historical notes separate from what your current interpreter actually does.

Allow about fifteen minutes for a first pass. You need a shell, the perl-doc package, and a test copy of the application if you plan to run its test suite. The examples are read-only unless marked otherwise, and none need elevated privileges.

1. Confirm the interpreter and documentation versions

Start by recording what is actually installed. This avoids the common mistake of reading a 5.8.8 change list and assuming it describes the Perl that will run your program today.

$ 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
$ command -v perl
/usr/bin/perl

Your version and package revision will differ. The checkpoint that matters is that the interpreter and documentation package are identified separately.

On a system without Debian package metadata, use perl -V:version and pull the package information from your normal package manager instead. Do not install an old Perl just to make this page's examples match: test a legacy application in an isolated environment if it genuinely needs Perl 5.8.8.

2. Read the release boundary before the details

Open the page directly and read its description first:

$ man perl588delta

The page describes differences between 5.8.7 and 5.8.8. It says no changes were intentionally incompatible with 5.8.7, but that statement is about one specific release transition. It is not a promise that code written for 5.8.8 behaves unchanged on Perl 5.38.2, or that every old module still exists.

For a non-interactive copy of the text:

$ man -P cat perl588delta > perl588delta.txt
$ grep -n -E '^(Core Enhancements|Utility Changes|Selected Bug Fixes|New or Changed Diagnostics)' perl588delta.txt

This creates a local notes file. It is safe to remove after the review with rm perl588delta.txt; if you want to keep it, put it in your project review area rather than overwriting an existing file without checking it first.

3. Check the changes that can alter source behaviour

Read the short sections before scanning the long module list. The core change lets chdir, chmod and chown accept filehandles when the operating system supplies the matching fchdir, fchmod or fchown call, which is conditional platform behaviour, not a guarantee for every Unix-like system.

The selected bug fixes make better test prompts than the headline. Perl 5.8.8 fixed:

• Selective no warnings 'category' handling when warnings were enabled with -w.
• Particular sprintf bounds problems.
• Debugger and Unicode slowdowns.
• Several ithreads leaks.
• Three-argument open handling with the open pragma.

Search your test suite for those features instead of assuming a general version bump is proof enough. Keep the old and new behaviour in separate tests: a warning test should assert the categories your application expects, while an I/O test should check the result of the open rather than matching a complete diagnostic string, since wording can change between Perl releases.

4. Review utility changes without touching the system

The release notes also cover utilities shipped with Perl. In 5.8.8, h2xs gained --use-xsloader, and perlivp gained -a to run all its tests, including checks no longer part of its default run. Inspect what is actually installed before copying an old command into a build script:

$ command -v h2xs perlivp
$ h2xs --help | grep -F -- '--use-xsloader'
$ perlivp --help | grep -E '(^|[[:space:]])-a([[:space:]]|,|$)'

A missing match is useful evidence: the current utility may not expose a historical option, or it may not be installed at all. Do not pass an option just because it appears in an old delta page; check the installed help and the current manpage first.

5. Turn the notes into a compatibility test

Make one test entry for each feature your application uses, including the Perl version, operating system, module versions and the exact command run. The module list in perl588delta is a useful inventory: it records upgrades such as CGI, Encode, Storable, Time::HiRes and Unicode::Collate, but it does not install or select those versions for you.

Run the application's own test command in a disposable checkout. A simple version gate establishes which interpreter a test job actually used:

$ perl -e 'printf "perl=%s\n", $^V'
perl=v5.38.2
$ perl -MConfig -e 'print "$Config{archname}\n"'
 x86_64-linux-gnu-thread-multi

Do not treat a clean exit alone as agreement with the release notes. Check warnings, generated files, Unicode input, debugger runs, thread-heavy paths and error handling where those features matter, and preserve the old test result before changing code so a later failure stays attributable.

6. Record the decision and stop at the right boundary

The review is complete once you can say which interpreter ran the tests, which 5.8.8 notes apply, and which claims stay conditional on the operating system or module version. If the review turns up a regression, keep the failing test and report the smallest reproducible case with perl -V, as the manpage requests. Do not put application data or credentials in a bug report.