Use perl5361delta to Check a Perl 5.36.1 Upgrade

You will finish with a small, repeatable review for a Perl 5.36.1 upgrade: identify the interpreter you are actually running, read the release-specific changes, check the bundled module version, and exercise a few relevant code paths. The review is useful on a server or workstation, but it does not install Perl or change system configuration.

Allow about fifteen minutes. You need a shell, Perl, and the perl-doc package if you want to use the installed manual directly. The examples are read-only apart from temporary files you choose to create. They do not need sudo.

1. Confirm which Perl you are reviewing

Start with the interpreter and documentation available on this machine. Do not assume that the perl found in your shell is the one used by a service, virtual environment or deployment script.

$ command -v perl
/usr/bin/perl
$ perl -V:version -V:archname
version='5.38.2';
archname='x86_64-linux-gnu-thread-multi';
$ dpkg-query -W -f='${Package} ${Version}\n' perl perl-doc
perl 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

Your paths and package revision can differ. The important distinction is that perl5361delta documents the change from Perl 5.36.0 to 5.36.1, whereas the installed interpreter above is Perl 5.38.2. Treat the manual as a release note, not as proof that this host is running 5.36.1.

Checkpoint: record the version, architecture and package source before comparing test results. If a service uses a different executable, run the same checks through that executable rather than substituting this shell's result.

2. Read the release note locally

Ask perldoc for the relevant document. This is an ordinary read-only command:

$ perldoc -T perl5361delta | sed -n '1,100p'

The document says that 5.36.1 has no intentionally incompatible changes relative to 5.36.0. It records an update of Module::CoreList, a build-system change for malloc() and free() probing on Solaris with a C++ compiler, and three interpreter fixes. It also says to read perl5360delta first when your starting point is earlier than 5.36.0.

Do not turn the phrase "no intentionally incompatible changes" into a promise that every application upgrade is risk-free. It describes the release's compatibility policy. Your application may still depend on modules, compiler behaviour, operating-system libraries or undocumented bugs.

3. Check the bundled module version

The release note records Module::CoreList moving from 5.20220520 to 5.20230423. Query the module that belongs to the interpreter you selected, rather than searching a separate Perl installation:

$ perl -MModule::CoreList -E 'say $Module::CoreList::VERSION'
5.20231129

A later version is normal when you are running a later Perl release. This command checks the local installation; it does not establish that an older 5.36.1 package is present. If Perl reports that the module cannot be found, inspect perl -V and the package contents before adding paths or installing anything.

Use the module's data for release questions, not for deciding whether your application itself is compatible. That still requires the application's test suite and its dependency lock or package metadata.

4. Exercise the documented evaluator fix

One 5.36.1 fix covered an eval used as the final statement in a regular-expression code block, where older interpreters could panic. A safe smoke test should be small and should report success explicitly. The following code keeps the regular expression harmless and does not read or write files:

$ perl -we '"abc" =~ /(?{ eval { 1 }; })/; print "regex-eval-ok\n"'
regex-eval-ok

This confirms that the selected interpreter completed the construct. It is not a full regression test for the historical crash, and a successful run on Perl 5.38.2 does not prove how Perl 5.36.0 behaved. For an upgrade decision, run the application's own tests under both the old and new interpreters where that comparison is possible.

5. Exercise a lexical-scope check

The release note also describes an assertion failure involving eval EXPR and a lexical sub defined in a grandparent scope. Keep the check isolated and make its result visible:

$ perl -we 'my $make = sub { my $value = "scope-ok"; sub { eval q{$value} } }; my $read = $make->(); die "unexpected result\n" unless $read->() eq "scope-ok"; print "lexical-eval-ok\n"'
lexical-eval-ok

If you adapt this for a test file, use use strict; and use warnings;, then assert the exact result your application requires. Keep the test under version control so it remains a regression check rather than a one-off command.

6. Keep output-handle tests separate

The third selected fix concerns writes to magic variables associated with the selected output handle, including $^, $~, $=, $- and $%, after the handle's IO object has been cleared. This is specialised formatter behaviour. Do not manufacture a production configuration change just to probe it.

If your application uses these variables, add a focused test around its real output-handling code. Run it in a disposable test process, capture its exit status, and retain the old output until the result has been inspected. A test that aborts can still leave a truncated file if its output is redirected directly to a valuable destination.

7. Separate source fixes from build fixes

The Solaris note is about Configure, not a runtime switch. It says that Perl stopped probing the return types of malloc() and free() because those types are defined by C, while command-line arguments and hints can still override them when necessary. If you are building Perl on Solaris with a C++ compiler, keep the complete configure command, compiler version and log with the build record.

Do not copy configure overrides from an unrelated host. First reproduce the build failure, then check the generated configuration and the compiler diagnostics. For a normal packaged Linux installation, this source-build detail is background information rather than a reason to change local settings.

8. Record the upgrade decision

Write down the interpreter path, version, architecture, package revision, module version and test results. Include whether the application was tested with its real service account. If a test fails, preserve the error and stop before changing dependencies or adding compatibility flags. A failed smoke test is evidence to investigate, not a prompt to silence the warning.

There is no undo step for the commands in this guide because they only inspect the installation or run short child processes. If you later install or replace Perl as part of a separate upgrade, use your distribution's package rollback or restore the previous interpreter and service configuration according to its change procedure.