It's all very subjective, of course. Of the four bonuses you've mentioned for use v5.12, the only one I would care about is the defined-or which I do find useful.

For 5.14, the only one there which I would care about is s///r but I use that so infrequently that it hardly matters. The big win for me with 5.14 is m//a which is a godsend when having to deal with the moving target that is the built-in character classes.

I don't really code for 5.6 these days beyond a couple of long-established modules where there is no reason to break it. The defined-or is the thing which most stops me from supporting 5.8 in new code.

So I am trying to transition from using Travis-CI for some of my Perl projects (and no CI at all for the rest) to using Github Actions for all of my Perl projects.

This is actually the point which interests me most. Why are you moving away from Travis?

I have been in the process of moving everything out of Github since the disaster. As even the stable releases would need an update if/when rt.cpan.org goes that will be the kick to move all the remaining stuff out too.

// was standard in 5.10 and available in 5.8.x with a series of patches, so that one is not the best reason to require 5.12 (instead of 5.10).

Using my version of perlver-fast:

$ perlver-fast -ve '$a //= 10'
-e: 5.010 / 5.010
5.010      //= operator
[download]

Whatever the reasoning behind a minimal requirement is, as long as the argumentation is good enough, it is acceptable.

Dropping support for alder perl releases does not mean that the releases of a module that are available on CPAN (and BackPAN) suddenly stop working.

If raising the minimal supported version of perl (for whatever reason) raises the quality as that increases test coverage, I won't object.

A reason not to raise that bar is if your module is way up-river, and thus also raises the minimal supported perl version to all the modules that require yours. Just something to consider.


Enjoy, Have FUN! H.Merijn

Last paragraph is why I'm proposing making 5.12 into more of a soft limit than a hard one. I'll be dropping automated testing on Perl 5.10 and below, but in most cases not deliberately killing off support.

For Exporter::Tiny and Type::Tiny, I guess it's worth still keeping explicit support for older Perls.

toby döt ink

GitHub Actions supports a wider variety of platforms (multiple versions of Ubuntu, multiple versions of Mac OS, and multiple versions of Windows), has some nice features like caching of dependencies between builds, and offers more concurrent processes. Those last two features allow builds to finish faster than Travis does, even if I'm now running more builds to cover more platforms.

Yeah, I can't say I was especially happy about Microsoft buying Github; they are not as bad as they once were, but will definitely need keeping a watchful eye on for the foreseeable future. However Microsoft have always relied on having support from grassroots developers, so in this case they have a strong incentive to not make a mess of things.

toby döt ink

Travis was bought last year and then laid off a good number of engineers. There are other options, like CircleCI and GitLab. If you're building your resume for enterprise grade clients, having active GitHub projects is a selling point. It may not be the most FOSS-y thing to do, but when you have to pay the bills then you do what needs doing.

tobyink:

While I'm not really qualified^[1] to have an opinion on the issue, you might consider looking for another "natural" breakpoint: specifically the lowest version that gets installed by default among various Operating Systems. I don't know what version^[2] that might be, but looking at your 'hoops' argument, I think it feels similar--when people set up a box, they're going to get some minimum version X, and if they need to install an older version to support some application, they'll have a similar circus act to follow.

I don't know if that would give a different result than your suggestion of 5.12 or not, I'm just offering another thing to think about. Personally, I like 5.12 as a minimum version because I use // quite a bit and state occasionally.

Notes:

1. I've never been primary production support on large systems, so while I'm somewhat of an old hand at using perl, I typically run the version that comes by default when I install a *NIX distribution or Cygwin on a Windows box.
2. Again, I don't support production systems, so I just grab a distro that I'd like to use and go with it.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

RHEL 7 has Perl 5.16. RHEL 6 has Perl 5.10(.1?). Ubuntu 14.04 has Perl 5.18.2.

But if someone's running a legacy OS, it's probably to support a legacy app, which can probably make do with an older version of my package.

toby döt ink

I collect what distro (276) ships with what perl release here as part of System::Info.


Enjoy, Have FUN! H.Merijn

RHEL6 does indeed have 5.10.1. However, it just went EoL at the end of last month so you could well feel justified in crossing that one off the list.

---

🦛

I am the least of the acolytes, but I have the gray hair of the aged and the round belly of the Buddha. Perhaps that counts for something?

With Perl 7 planning to be 5.32 rebranded and cleaned up, I would recommend focusing on that. Instead of an incremental increase, 5.4 to 5.12, you gain a significant step forward *and* you gain stronger marketability. A customer doesn't care about upgrading from 5.4 to 5.8, or 5.12. It costs them admin and developer time and buys them nothing. It buys *you* something, but the customer pays the cost.

I'm personally tired of seeing job postings for "modern" languages when the listing doesn't include Perl. Okay, Perl isn't modern and cool and hip-ster like Ruby or Python. Perl is a lot harder; but if I can code OOP in Perl then a "modern" language like Python or Ruby won't be much trouble at all.

Perl 7 is a larger move and an easier sell. It buys us a lot more than an incremental increase. Yes, the last major update might not have gone as planned, but if we learn the lessons then this one might be a huge win for all of us.

So you are suggesting I drop support for Perl versions older than Perl 7, which hasn't even been released yet?

toby döt ink

Code clean up and support is an exhausting task, so the more "bang for your programming buck" you can get, the better off you'll be. I think a lot of good things might happen with a working Perl 7 release. Since Perl 7 is supposed to be compatible with Perl 5.32, then you can focus development branches on 5.32 and easily migrate to Perl 7 when it works. Communicate to your user base about the 5.32 development branch, and give everyone plenty of time to update or migrate.

What's the best way to delight yourself and your user base? Choose that.

After reading Dan Book's Risk-Benefit Analysis and his Recommendation, I'm less hopeful for Perl 7. And in that, I'm not sure the concepts of "modern", and "Perl" blend well.

There is a lot of older Perl code out there. it's easy to find "modern" languages that do this or that, and coders flock to them with great joy. They also flock up the internet with ideas about what a language should look like and what new toys are important at this moment. While good code can be artistic, code isn't art. Its syntactical balance and arrangement are secondary to a pragmatic "does it work?" No matter how pretty (Object Oriented, Functional, whatever the cool paradigm is today) it is, code must work to have any value.

We can produce working code in Perl. Because of the Perl team's herculean efforts at backward compatibility, we can produce very long lived code in Perl. I can write Perl 5.8 compliant code that gets the job done. Perl 5.8 is old enough to vote in the USA! More to the point, if I can get the job done in Perl 5.8 then I don't really need new things from 5.12+. Later Perls add tools that developers like, but if the code works then the end user doesn't really care about the version.

While dropping support for older Perls makes workforce sense, it hurts Perl overall. We will lose users because the code no longer works and CPAN modules won't easily install. However, the support cost to you and others is high. I certainly won't fault you for dropping support for older versions.

Do what is best for you, as each of us should. My code must meet certain requirements, and "work on the customer's old Perl version" is one of them. I had hoped Perl 7, while a ways off, would give us a way to talk customers into moving forward. It seems my idealism might be misplaced.




Addendum I was messing around with MariaDB 10.5.8, the mostly latest, and the "server" rpm includes Perl files, including one originally written in 1998.