(cross-posted from my blog)

Last Monday I did the Perl Developer Release of Perl 5.43.7. As usual, I worked from the Release Managers Guide . Everything worked well, even if everything was cutting it a bit close. My video setup on the desktop was not suited for streaming anymore, so I had to do a stream consisting only of the console window and me talking over it, and no floating head of me available.

What worked well

The Twitch chat was the most active that I witnessed when streaming a Perl release. We chatted about organizing Perl conferences and also the Perl release process. One realization for me was that the RMG process is mostly there to exercise the Perl build machinery and testing that the generated tarball does not have deficiencies. This means that testing that Perl can build through Configure is important, but testing different Perl configurations like ithreads or userelocatableinc is not that important.

The dashboard for tracking my progress through the release worked well up to the release. I had modified it in the weeks leading up to the release to not only show the human step description but also to show the command line steps that should be undertaken, where applicable. I see this as a first step in automating these steps where possible and sensible.

What didn't work out

The dashboard can use some improvements:

• The script did not cope well with the events after the release when the repo version number was bumped from 5.43.7 to 5.43.8. This part needs to be investigated but is easy to replicate by simply launching the dashboard with a version number before the current version number.

• The script could highlight the current position in the sequence better. For console output this would likely mean inverting the line where the next applicable step is, but this means moving the output from Text::Table to a custom table generation or post-patching the string from Text::Table with the appropriate console commands.

• The script should generate HTML and terminal output at the same time. Having output visible in a browser feels less retro but makes things like publishing the progress elsewhere easier.

• The script should have a feature to simply output the next step. This could be integrated into the shell prompt to give a guided message in the console window. Maybe the console output and the HTML output should be done as files when in "interactive" mode?

Improvements to the Perl Release Process

• More parallelism - the current release manager guide uses make test in many places. This runs the test suite in serial mode, which takes on my machine about 10 minutes. Running the test suite in parallel takes about 4-5 minutes. This is implemented using the make test_harness command. Whether Perl should move the default of parallel testing to make testfrom make test_harness is debatable. Most likely everybody who cares about speed already runs the test suite in parallel.

• Remove sequences of shell commands - comparing the file names between the previous and current Perl version is done using a sequence of shell commands involving sort, diff`. I have a patch that adds a small tool to do that within Perl (mostly powered by Algorithm::Diff ).

Taking a break from promotional posts about the German Perl Workshop, I also posted on
my personal blog about what I released in 2025.

I find such retrospectives always interesting, finding out which modules had staying power,
which modules needed no changes during the year, and which modules still are
under development.

I was on the schedule for 2025, but by swapping the release version, I skipped doing a release in 2025. This year, I'm doing the dev release live stream again on Twitch, for version 5.43.7.

And again, you can watch it live on Monday 19th of January on Twitch.

You can expect to watch me talk through the steps of the Perl Release Managers Guide and if you join the Twitch chat, or

p5p on irc.perl.org, we can chat a bit.

I assume I'll start Monday at 16:00 UTC (17:00 CET), and the whole thing will take around 4 hours unless there are some major mishaps. In the middle, I'll join a call of the organizers of the German Perl Workshop 2026 in Berlin, where we will likely go through organizing the social event and the pre-conference meeting.

I skipped 2023 but in 2024 I'm actually doing two dev releases of Perl again. This time it is version 5.41.7.
And again, you can watch it live on Friday 20th of December on Twitch.

Crossposted from my blog

My upgrade of my home server from Debian 11 ("bullseye") to Debian 12 ("bookworm") went almost without a hitch. Yesterday I realized that the Postgres data hadn't been migrated from the old DB to the Debian package of Postgres 15. But luckily, the good Pg people provide a Debian package of 9.6 (the version which held my data) for Debian 12. I could install that one, fire it up, dump all data into SQL, fire up Pg 15 from Debian and import it there. Now I run such an SQL dump daily, just to have the data available as SQL files.

I wonder if it would be worthwhile for Perl to provide prebuilt binaries/packages of old Perl versions for current OSes, but then, there are so many build options that it's not worth the effort in general.

The only use case I see would be to provide an emergency Perl when your dist-upgrade nuked the system Perl [^1] , but some custom XS modules or XS modules installed via cpan instead of the package manager relied on that version. This would reduce the number of build options, but I'm still not sure if that actually helps anybody.

Maybe simply taking the (Debian) build files for old packages/distributions and running them for new distributions, with a prefix of /opt/perl5-xx could already help. People would still need to edit the path of their scripts to bring things back up.

This only makes sense when also rebuilding all the old CPAN modules for the new OS version, except under /opt. That's a lot of effort for little to no gain, except when people really need it.

[^1] : well, not nuked, but replaced with a newer major version that is not binary compatible

After inspiration by a comment on Perlmonks.org and some slight hacking, I'm very proud to announce HTTP::Request::FromCurl, together with its companion online site at https://corion.net/curl2lwp.psgi. The module and included curl2lwp program allow you to easily convert curl command lines to Perl code that uses LWP::UserAgent resp. WWW::Mechanize.

The ambush of WWW::Mechanize::Chrome shows more fallout before the module itself has been released. The module is one in a long line of browser automation modules I wrote, starting with WWW::Mechanize::Shell, reaching is breakthrough with WWW::Mechanize::Firefox and continuing from WWW::Mechanize::PhantomJS to WWW::Mechanize::Chrome.

In April, Google announced that Google Chrome was finally supporting headless mode, at least on Linux and Mac OS. Back then, I noted to myself that this might be a good time to revisit my rough prototype of WWW::Mechanize::Chrome. According to Git, I had written a first prototype of it in 2010 which used the old, raw socket protocol. But time has progressed and the protocol now uses Websockets. My original approach used AnyEvent, so I quickly replaced my own approach using AnyEvent::WebSocket::Client, and the HTTP parts with Future::HTTP.

Do not ask what Perl can do for you, ask what you can do for Perl!

In my effort to bring the new signature back to older versions of Perl, I'm maintaining Filter::signatures, a source filter that simply converts the signatures to the equivalent old-style Perl code. That filter works surprisingly well for its simplicity and has caused very little in problems.

I don't mind working with Spreadsheets. Much of my work consists of creating Spreadsheets from SQL queries. Sometimes, the resulting spreadsheet should be a pivot table, listing some values across the spreadsheet. For most of my Spreadsheet-generation needs, Querylet is sufficient, but it cannot create pivot tables.