in reply to Deciding dependency versions

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.

[Note: I've made reference to v5.16.3 based on what you wrote in "Re^2: Multidimensional arrays".]

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;

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

use 5.006;

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

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

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
"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

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', },

[Aside: Nothing to do with your question, but I thought I'd alert you to a security vulnerability in HTTP::Tiny. See: "CVE-2023-31486"; "RFC: Making SSL_verify safer"; "Change verify_SSL default to 1, add ENV var to enable insecure default".]

— Ken

Replies are listed 'Best First'.
Re^2: Deciding dependency versions
by Bod (Parson) on Jun 10, 2023 at 21:28 UTC

    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

      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

        Older versions of perl (where old is very relative) will also be seen a lot on EOL Os's and OS releases where the (end-)user has no means to update/upgrade to a newer release. This includes OS's like AIX, HP-UX, Solaris, and Irix (and a lot of others) that still run production code but do not support major updates/upgrades for vital software. Sometimes life sucks.


        Enjoy, Have FUN! H.Merijn
        I didn't think that would be enough, so I ran some tests

        Thanks kcott. Very much appreciated that you took the time to test it.

        Do you feel it is worth shipping an update to include use VERSION or am I relatively safe to wait until another update is needed?

        5.8 & 5.10: there seems to be a small number of ISPs, with minimal Perl support, who provide these versions

        Very timely as this morning I've had a FAIL from CPAN Testers :(

        After some investigation, it seems that I've used the defined-or operator that was new in v5.10. So, now I have to decide whether to support a 16-year-old version of Perl or set the minimum version at v5.10. If it wasn't a "small number of ISPs" that are using v5.8 then it would be an easy choice as the module is useless without an active network connection to call the APIs.

        I was very surprised to note the time between v5.8 (2003) and v5.10 (2007)

        This has also got me looking back at Business::Stripe::WebCheckout where there have been some N/A CPAN Tester reports. I'd thought that was because of the minimum Perl version but it isn't. Instead it seems to be that the tester didn't have the required version of ExtUtils::MakeMaker installed so didn't run the tests. This module would also fail on Perl v5.8...

        Interestingly, the Wikipedia article on Perl version lists v5.16 onward as "toolchain" and v5.14 backwards as "legacy". So a case could certainly be made to not support anything prior to v5.16.