Short answer: select the minimum versions you have tested.

Given these are core modules, a reasonable thing to do would be to consider the minimum version of perl you think you'd be prepared to support, install it locally (eg with perlbrew) to check that your tests pass on that version, and then specify the versions that shipped with that release.

I don't know anything about Stripe, but I'm guessing that a good number of the type of people that would want to use your module will be small-business owners that would not want to modify the perl their OS ships with (nor install an additional perl), so the earlier the version you can support the more people you will be able to serve.

Perl ships with a program corelist which will help with information about versions of modules in the various releases of perl it knows about. Note that when it says "Digest::SHA was first released with perl v5.9.3", a development release, that implies the first full release will have been v5.10.0:

% perl -v | head -2
This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-li
+nux-gnu-thread-multi

% corelist Digest::SHA
Data for 2017-09-22
Digest::SHA was first released with perl v5.9.3

% corelist Digest::SHA -v 5.10.0
Digest::SHA 5.45

% corelist -a Digest::SHA | grep '[02468]\.0 '
  v5.10.0    5.45
  v5.12.0    5.47
  v5.14.0    5.61
  v5.16.0    5.71
  v5.18.0    5.84
  v5.20.0    5.88
  v5.22.0    5.95
  v5.24.0    5.95
  v5.26.0    5.96
%
[download]

I don't know anything about Stripe, but I'm guessing that a good number of the type of people that would want to use your module will be small-business owners that would not want to modify the perl their OS ships with

I reckon that would be a very accurate assumption...

For that reason, for the Perl version I start with v5.006 (because that's what Module::Starter specifies for Makefile.PL and check to see if I am using any Perl features that were not in that version. If I am, I ask myself if my code benefits from the later features. So, I have process I am happy with for selecting the minimum Perl version.

Additionally, I have v5.16.3 running on my hosting so (almost) everything gets tested on that. I don't feel there is any need to support anything older but I will if it is only a case of changing a digit in Makefile.PL

Perl ships with a program corelist

Thanks for that - I didn't realise that. This will save me time looking up release versions in the online documentation :)

Well, I'm going to guess you haven't tested it on perl-5.006, since JSON::PP starts with a use 5.008. :)

G'day Bod,

I was going to provide an answer specific to your Business::Stripe::Webhook module; however, the link you provided resulted in "Error 404 - Not Found", so I can't do that.

I see ++hv has already supplied an excellent response. The information I've given below is intended to be complementary.

Do you have a 'use VERSION;' statement in your code? I'd generally consider it to be a good idea to include one; although, it's not essential. In Makefile.PL, a MIN_PERL_VERSION entry should mirror this.

"The modules I have selected are all core."

They may be core in v5.16.3 but not necessarily in your MIN_PERL_VERSION. I assume you have this code:

use strict;
use warnings;
[download]

As warnings is not dual-life (i.e. can't install separately from CPAN), you'll need at least:

use 5.006;
[download]

based on:

$ corelist strict warnings

Data for 2022-05-27
strict was first released with perl 5

Data for 2022-05-27
warnings was first released with perl v5.6.0
[download]

Here's when the modules that you listed first entered core:

$ corelist JSON::PP HTTP::Tiny Digest::SHA Time::Piece

Data for 2022-05-27
JSON::PP was first released with perl v5.13.9

Data for 2022-05-27
HTTP::Tiny was first released with perl v5.13.9

Data for 2022-05-27
Digest::SHA was first released with perl v5.9.3

Data for 2022-05-27
Time::Piece was first released with perl v5.9.5
[download]

And here's the versions you'd get with v5.16:

$ corelist -v 5.016 JSON::PP HTTP::Tiny Digest::SHA Time::Piece
JSON::PP 2.27200
HTTP::Tiny 0.017
Digest::SHA 5.71
Time::Piece 1.20_01
[download]

"I strongly suspect that I could go for earlier ones ..."

As you wind back your MIN_PERL_VERSION, you'll need an increasing number of modules from CPAN. Some examples (undef indicates not in core for that Perl version):

$ corelist -v 5.010 JSON::PP HTTP::Tiny Digest::SHA Time::Piece
JSON::PP undef
HTTP::Tiny undef
Digest::SHA 5.45
Time::Piece 1.12

$ corelist -v 5.008 JSON::PP HTTP::Tiny Digest::SHA Time::Piece
JSON::PP undef
HTTP::Tiny undef
Digest::SHA undef
Time::Piece undef
[download]

Unless module installations are performed manually, utilities like cpan and cpanm will install the latest from CPAN. These modules may have dependencies with later versions (than those in core) and will also need to be installed.

As I believe you're using Strawberry Perl, you can install different Perl versions using berrybrew. I haven't used it myself, but have heard good things; and the author is fellow monk stevieb, so I'm sure you could get good support if that's needed.

Install v5.14; don't add any CPAN modules; add your Business::Stripe::Webhook code; and see if that works without any problems. Repeat with other Perl versions. Try with just a few CPAN installations. You could end up with something like this in Makefile.PL

MIN_PERL_VERSION => 5.012,
PREREQ_PM => {
    Digest::SHA => 0,
    Time::Piece => 0,
    JSON::PP    => '2.27200',
    HTTP::Tiny  => '0.017',
},
[download]

Thanks for all the excellent information. I shall use this to be a bit more rigorous when I release an update or a new module.

Do you have a 'use VERSION;' statement in your code?

No, I don't - I rely on Makefile.PL do specify the minimum Perl version. Having said that, I can usually specify such an old version of Perl that everyone will almost certainly have the minimum required.

Is there any data anywhere on how many people are actually using really old versions of Perl? Does CPAN collect it from install requests?

"I rely on Makefile.PL do specify the minimum Perl version."

I didn't think that would be enough, so I ran some tests.

ken@titan ~/tmp/pm_11152747_min_ver
$ module-starter --module=Bod::Min::Ver
...
Created starter directories and files

$ cd Bod-Min-Ver

# Modified lib/Bod/Min/Ver.pm
package Bod::Min::Ver;

#use v5.36; <--- commented out

our $VERSION = '0.001';

print "$^V\n"; <--- newly added

# remainder unchanged

$ cat Makefile.PL
...
   MIN_PERL_VERSION    => '5.036',
...

$ perlbrew switch perl-5.34.0

$ perl -v | head -2 | tail -1
This is perl 5, version 34, subversion 0 (v5.34.0) built for cygwin-th
+read-multi

$ perl Makefile.PL
Checking if your kit is complete...
Looks good
Warning: Perl version 5.036 or higher required. We run 5.034000.
Generating a Unix-style Makefile
Writing Makefile for Bod::Min::Ver
Writing MYMETA.yml and MYMETA.json

$ make
cp lib/Bod/Min/Ver.pm blib/lib/Bod/Min/Ver.pm
Manifying 1 pod document

$ make test
...
t/00-load.t ............. Perl v5.36.0 required--this is only v5.34.0,
+ stopped at t/00-load.t line 3.
... all other tests failed in a similar fashion ...

$ perldoc lib/Bod/Min/Ver.pm
... POD template shown correctly ...

$ perl -e 'use lib "./lib"; use Bod::Min::Ver'
v5.34.0
[download]

So, `perl Makefile.PL` only provides an advisory warning, and module can still be loaded with a Perl version earlier than MIN_PERL_VERSION.

Recommendation: include "use VERSION;".

"Is there any data anywhere on how many people are actually using really old versions of Perl?"

It's possible that there's usage information somewhere, maybe from some sort of survey, but I'm unaware of such; perhaps another monk knows.

My guesses would be (mostly based on SoPW posts that I remember):

• 5.6 and earlier: a very small number; mostly academic interest and hobbyists.
• 5.8 & 5.10: there seems to be a small number of ISPs, with minimal Perl support, who provide these versions.
• 5.12 and later: probably depends on whether you categorise these as "really old versions". My "Out-of-the box Perl version - lowest common denominator" post, from a couple of years ago, may provide some insights.

"Does CPAN collect it from install requests?"

That seems unlikely. After downloading a module tarball (which may not even involve Perl) there's no further interaction with CPAN directly.

— Ken

There are three levels in that answer, and you can control all of them in cpanfile and Makefile.PL.

1. The minimum version that your module requires to function as described. This might imply that some features are not supported, but you guarantee that your module passes tests when used with this version. In you meta, that would be required. It is completely up to you to raise that minimum for whatever reason even if you know it would work as well with a lower version. In that case I'd like to read about the reasoning in the README.md or equivalent.
2. The version that you recommend. There might be several reasons for that: fixed CVE's, added functionality, raised stability, easier API, …. Again, fully your choise. You can mention that in the recommends sections of your meta. If you state a recommended version, end-users expect you to have tested your module with this.
3. Last is the section suggested. You might want to have this when it features optional new stuff, speeds increases or whatever.

Here is an example from cpanfile for the dependency on ExtUtils::MakeMaker, based of availablility and solved CVE's:

on "configure" => sub {
    requires   "ExtUtils::MakeMaker";
    recommends "ExtUtils::MakeMaker"   => "7.22";
    suggests   "ExtUtils::MakeMaker"   => "7.70";
    };
[download]