Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Deciding dependency versions

by Bod (Vicar)
on Jun 09, 2023 at 22:52 UTC ( #11152723=perlquestion: print w/replies, xml ) Need Help??

Bod has asked for the wisdom of the Perl Monks concerning the following question:

When releasing a new module, how do you decide which minimum version of the dependencies to require?

I am about to release Business::Stripe::Webhook and it has these dependencies in Makefile.PL:

PREREQ_PM => { 'JSON::PP' => '2.00', 'HTTP::Tiny' => '0.014', 'Digest::SHA' => '5.94', 'Time::Piece' => '1.32', },
The modules I have selected are all core. I've approached the minimum version by firstly checking what version I have installed. That sets the maximum I need to specify. Then to look at the module's CHANGES file and work back until I see a change that I think might affect my module and select the version after that.

I strongly suspect that I could go for earlier ones but don't want to risk my code breaking because of a broken dependency. That's just annoying and frustrating for everyone. Equally, I don't want to force people to update every module if it is not necessary.

So, how do you select the minimum version number for your dependencies?

Replies are listed 'Best First'.
Re: Deciding dependency versions
by hv (Prior) on Jun 10, 2023 at 00:01 UTC

    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 %
      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. :)

Re: Deciding dependency versions
by kcott (Archbishop) on Jun 10, 2023 at 05:19 UTC

    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

      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

Re: Deciding dependency versions
by Tux (Canon) on Jun 11, 2023 at 10:36 UTC

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

    Enjoy, Have FUN! H.Merijn

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://11152723]
Approved by kcott
Front-paged by hippo
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (2)
As of 2023-10-01 12:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?