Audit a Perl 5.8.6 Upgrade with perl586delta

Read perl586delta before you touch a Perl 5.8.5 to 5.8.6 upgrade, then turn its claims into tests instead of trusting them on faith. Budget about 20 minutes for a small script, longer if it uses XS modules, threads, taint mode or embedded Perl.

This is a historical comparison between Perl 5.8.5 and 5.8.6, not a promise about every later release. The interpreter on this machine is Perl 5.38.2, so treat every example below as a way to inspect current behaviour, not as proof that this box is running a 5.8.6 installation.

1. Record the interpreter and manual you are using

Start without elevated privileges. The command name perl can resolve to a different binary for a service, a virtual environment or a shell, so record the executable path as well as its version:

$ command -v perl
/usr/bin/perl
$ perl -v
This is perl 5, version 38, subversion 2 (...)
$ man perl586delta

Your version line and build details will differ. Repeat the check under any service account that runs a different Perl.

2. Confirm the compatibility boundary

The 5.8.6 notes state there are no changes incompatible with 5.8.5, which is useful evidence for a point-release review but no substitute for testing your own code. The same notes call out:

• UTF-16 script handling changes.
• A Win32 networking change.
• Module revisions across the core distribution.
• Several bug fixes covered in the next sections.

Make a short inventory of the parts your application actually uses:

$ perl -MConfig -e 'print qq($Config{version}\n$Config{archname}\n)' 
$ perl -MCwd -MEncode -MTime::HiRes -e 'print qq(core modules load\n)'
core modules load

The first command reports the interpreter version and architecture. The second is a load smoke test for three modules named in the notes. A non-zero exit status needs investigation before an upgrade, and you cannot infer a module's historical version from the current interpreter: Perl 5.38.2 has moved far beyond what shipped with 5.8.6.

3. Exercise the changed sorting behaviour

Perl 5.8.6 documents an optimisation for reverse sort and for iterating with for (reverse @foo): the result should be identical, only the temporary intermediate list disappears. Test the result your program actually relies on:

$ perl -e '@x = qw(beta alpha gamma); print join(q{,}, reverse sort @x), qq(\n)'
gamma,beta,alpha
$ perl -e '@x = qw(one two three); print join(q{,}, reverse @x), qq(\n)'
three,two,one

These examples check ordering, not memory use. For a real application, run its existing test suite and compare output or saved fixtures before and after the interpreter change. A failed test is a release blocker, not something to patch by rewriting the test to match.

4. Check stable sorting where ties matter

Perl had promised stable sorting since 5.8, but two descending comparator forms could break that promise. If your program sorts records with equal keys, add a fixture that makes the original order visible:

$ perl -e '
  @rows = ([1, q(first)], [2, q(other)], [1, q(second)]);
  @rows = sort { $b->[0] <=> $a->[0] } @rows;
  print join(q(,), map { $_->[1] } @rows), qq(\n);
'
other,first,second

The two records with key 1 keep their original order. Test the comparator your application actually uses, including the string form $b->[0] cmp $a->[0] where that is what the code uses. Stability only guarantees order among equal keys, not between different ones.

5. Verify the new debugger flag without changing files

Perl 5.8.6 added -dt, which enables threads support in the debugger. It opens an interactive session, so use a trivial program and quit at the prompt rather than attaching it to a service:

$ perl -dt -e 'print qq(debugger smoke test\n)'
Loading DB routines from perl5db.pl ...
main::(-e:1):   print qq(debugger smoke test\n)
  DB<1> q
Quit

Debugger wording, prompt formatting and the displayed source line vary by build. What matters is that -dt is accepted and the debugger starts. If your installed Perl rejects it, do not add it to a production wrapper: the local interpreter is not the version this note describes.

6. Cover the risk areas named by the notes

Do not try to reproduce every old memory leak or XS crash with an ad hoc one-liner. Map the notes to tests you already trust instead:

• Run UTF-8 and invalid-input tests if an XS module hands data to the regular-expression engine.
• Run shared-array tests if the application uses threads::shared.
• Run deep recursion and chained goto & tests if those constructs are present.
• Run taint-mode tests and confirm -T is supplied on the command line when the shebang requests it.
• Run tests around read offsets, overloaded numeric comparisons and array deletion if those operations are part of the application.

The manual describes fixes for these areas, not new switches you must enable. A fix should make an existing regression test pass; it should never require a new application setting.

7. Plan the change and the undo path

Before changing a system Perl, save the package version, interpreter path, application test result and service configuration in your change record. The upgrade can affect scripts, modules and embedded Perl even when the notes report no incompatible changes. Keep the old package available through your distribution's normal rollback process.

The notes also mention safer environment handling for applications that embed Perl. Treat that as an integration test item: rebuild or restart the embedding application in a test environment and check how it reads and changes environment variables before scheduling production work.