Read Perl 5.34.1 Release Notes Before You Upgrade

You will finish with a short, repeatable check for what changed between Perl 5.34.0 and 5.34.1, plus a clear boundary between those historical release notes and the Perl version installed on your Linux host. The guide uses perl5341delta, the release-note manual page supplied by perl-doc.

Allow about ten minutes. You need a shell and the perl-doc package. The commands are read-only and do not need sudo. The examples below were checked on a host with perl-doc and Perl 5.38.2 installed.

1. Confirm which manual page you have

Start by checking the package that owns the file. This prevents a missing manual page or a different installation from distracting you from the actual release notes:

$ dpkg -S /usr/share/man/man1/perl5341delta.1.gz
perl-doc: /usr/share/man/man1/perl5341delta.1.gz
$ dpkg-query -W -f='${Package} ${Version}\n' perl-doc
perl-doc 5.38.2-3.2ubuntu0.6

The package version is the distribution package version, not the Perl release described by the page. Here, the installed package is from Perl 5.38.2, while the document describes the older 5.34.1 maintenance release.

Checkpoint: if dpkg -S reports no owner, install nothing as part of this guide. Find the correct package for your distribution, or inspect the path printed by man -w perl5341delta first.

2. Open the release notes in the terminal

Use man for a paged view:

$ man perl5341delta

The page identifies itself as "what is new for perl v5.34.1". It compares 5.34.0 with 5.34.1. It also says that an upgrade from an earlier release, such as 5.33.0, should first be read alongside perl5340delta. That is a scope boundary, not a suggestion to assume that one page contains every change since your current version.

For a command that is easier to capture in a ticket or review note, use perldoc without a pager:

$ perldoc -T perl5341delta | sed -n '1,24p'
NAME
    perl5341delta - what is new for perl v5.34.1

DESCRIPTION
    This document describes differences between the 5.34.0 release and the
    5.34.1 release.

-T requests plain text output. The sed limit only controls how much you display; it does not alter the installed documentation.

3. Read the compatibility statement first

Before focusing on individual modules, find the Incompatible Changes section. For 5.34.1, the page says that there were no changes intentionally incompatible with 5.34.0. It also leaves room for bugs, so treat that sentence as a release-level compatibility statement, not proof that every application or third-party module will behave identically.

Do not turn the statement into a blanket upgrade approval. A maintenance release can still matter to a service because of bug fixes, module updates, platform support, or packaging choices. Test the application that actually runs on your host.

4. Record the module changes

The page lists five updated components. Capture them as a review checklist rather than copying the whole page into your notes:

These are versions in the release notes, not commands that will necessarily return those values on your machine. A newer Perl installation can legitimately report newer versions.

Checkpoint: ask the local interpreter what it has, using module variables where they are available:

$ perl -MConfig -e 'print "$Config{version}\n"'
5.38.2
$ perl -MB::Deparse -MEncode -MGDBM_File -MModule::CoreList -e 'print "B::Deparse $B::Deparse::VERSION\nEncode $Encode::VERSION\nGDBM_File $GDBM_File::VERSION\nModule::CoreList $Module::CoreList::VERSION\n"'
B::Deparse 1.74
Encode 3.19
GDBM_File 1.24
Module::CoreList 5.20231129

Your output will depend on the Perl installation and distribution packages. If a module is not installed or cannot be loaded, record that as a test condition instead of inferring its version from the delta page.

5. Check the fixes and platform note

The selected bug-fix notes concern B::Deparse handling of more complex try/catch scopes and try/catch returning the last evaluated expression when a catch block has more than one statement. The page also records support for compiling Perl on Windows with Microsoft Visual Studio 2022. The latter does not change how a Linux binary behaves.

If your application uses the affected Perl features, make a small regression test in the application's own test suite. Do not use the release note alone as a test result. The practical check is to run the existing suite with the interpreter that will serve the application:

$ command -v perl
/usr/bin/perl
$ perl -v | sed -n '1,4p'

This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-gnu-thread-multi

Keep this step read-only while investigating. A production upgrade changes the interpreter used by services and jobs, so plan a rollback before changing packages or service configuration. If you have already changed a package in a separate maintenance procedure, restore the previously approved package version using your distribution's package-management process; there is no undo action in perl5341delta.

6. Follow the reporting boundary

The manual page points bug reports to the Perl issue tracker and tells you to reduce a suspected defect to a tiny sufficient test case. For a security issue, it directs you to the security contact information in perlsec instead of putting sensitive details in a public issue.

Keep those paths separate. A missing module, a packaging mismatch and a reproducible Perl bug need different evidence. Include the exact interpreter version, the relevant delta section, a minimal test and the command's exit status. Never paste credentials, private input or production data into a public report.