Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Which version to target for module dependencies?

by xdg (Monsignor)
on Aug 17, 2005 at 03:19 UTC ( #484300=perlquestion: print w/replies, xml ) Need Help??
xdg has asked for the wisdom of the Perl Monks concerning the following question:

Dear fellow monks, I'm interested in hearing your philosophies, practices, opinions and/or rants about what version of module dependencies to list in a Makefile.PL or Build.PL. I've been pondering this for a while (and churning some of my modules on CPAN to fiddle with dependency versions) and have yet to come up with a "system" I'd want to apply consistently.

I see several extremes and some painstaking middle ground:

  1. Just list all prerequisites as needing version "0" -- take any version and let the module user hope that their modules are sufficiently up to date to run without problems and bugs. E.g.:

    # From a Build.PL requires => { Scalar::Util => 0, Test::Exception => 0, Test::More => 0, }
  2. Whenever updating the module, update all dependencies to their latest and greatest versions on CPAN -- causing builds to fail whenever an installer has old versions that can't/won't be updated (legacy support; binary PPM/RPM release cycle, etc.). E.g. (as of today, anyway):

    requires => { Scalar::Util => 1.17, Test::Exception => 0.21, Test::More => 0.60, }
  3. List whatever version of dependencies happen to be installed on the development machine -- i.e. use at least one known working configuration that passes all test as the minimal standard. E.g. (for my Win32 ActiveState Perl 5.8.7, at least since the last time I updated anything):

    requires => { Scalar::Util => 1.14, Test::Exception => 0.20, Test::More => 0.54, }
  4. Work out exactly when certain necessary features became available in each dependency or when significant bugs were fixed -- potentially painstaking and really hard to regression test. E.g. (somewhat contrived):

    requires => { Scalar::Util => 1.09, # first appearance of refaddr() Test::Exception => 0.21, # 0.20 doesn't build well with CPANPLUS Test::More => 0.48, # thread safe }

None of these jump out at me as an "a-ha!" approach that I like.

What other philosophies do people have on this? Is it different for ordinary CPAN modules versus core modules (that may or may not have updated versions on CPAN not yet in core)? Are there certain versions that you target for certain modules no matter what? (E.g. Test::More has morphed rather substantially since it was last included in a core release.)

Your input is greatly appreciated. Regards,


Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re: Which version to target for module dependencies?
by brian_d_foy (Abbot) on Aug 17, 2005 at 05:06 UTC

    My general rule for dependencies goes for the lowest version that will work. I start off with version '0', and then change that if I need something specific.

    I try very hard to avoid using new features of modules just because I can. A lot of the people I work with can't simply install ne modules like I can. For that reason, I don't simply list the latest and greatest version on CPAN.

    It usually takes someone telling me that my module doesn't work with some version until I change the pre-requisites. The tough part is that the modules usually break with later versions, not earlier ones.

    brian d foy <>
Re: Which version to target for module dependencies?
by GrandFather (Sage) on Aug 17, 2005 at 03:44 UTC

    Option 3 looks like a reasonable compromise to me. It is a tested configuration and has to count for a lot! Option 2 is too agressive. Option 1 is altogether too nasty and option 4 is more work than most people could be expected to do.

    Perl is Huffman encoded by design.
Re: Which version to target for module dependencies?
by mirod (Canon) on Aug 17, 2005 at 05:26 UTC

    I agree with brian_d_foy, list a minimum version in the dependency only if you know that earlier versions break the module. The same thing goes with versions of perl BTW, there is no need to start with use 5.8.7 if the module might work in 5.6.2... or 5.004!.

    This way you will start with #1 and eventually end up with #4.

    Of course this will work best with good test coverage (Devel::Cover is your friend), and it can be a real a pain to make sure your tests work with old versions of perl, but I think this is the right thing to do.

Re: Which version to target for module dependencies?
by Tanktalus (Canon) on Aug 17, 2005 at 04:08 UTC

    I agree with GrandFather. I just go with 3. Worst case scenario for those who can't upgrade to these levels is that they go in and modify the Makefile.PL or Build.PL of the tarball they just downloaded to fake it - but they can then understand if something breaks because of it ;-)

Re: Which version to target for module dependencies?
by tlm (Prior) on Aug 17, 2005 at 14:36 UTC

    I think the answer is somewhere between 3 and 4, and beyond this point the decision is based solely on how polished one wants one's CPAN module to be. We have to make a similar decision (i.e. how much work do we want to put into something) with just about everything we do. If you go with 3, maybe you can alert users that some earlier versions of the dependencies may work, and leave it up to them to do the final polishing of the piece.

    the lowliest monk

Re: Which version to target for module dependencies?
by jkeenan1 (Deacon) on Aug 18, 2005 at 14:11 UTC
    In general I agree with tlm that the answer lies somewhere between 3 and 4. But I also think you're on to something when you suggest different approaches to core and non-core modules. So at the risk of suggesting an approach #5 ...

    With core modules I ask: "What version of Perl am I requiring? Was the module I'm listing as a dependency distributed with Perl in that version? And, if so, did it lack any features at the time it was introduced to core that I now want?"

    If the answer to the that last question is yes, then I have to go to that module's Changes file, see when the desired feature was introduced, and explicitly list that in Makefile.PL. If the answer is no, then a simple require [targeted perl version] takes care of the problem.

    The answer to the second problem can be approached with RafaŽl Garcia-Suarez's Module-CoreList.

    The answer to the first problem is to ask, "How backwardly compatible do I want my module to be?" If the code is going up on CPAN for universal use, then you may want considerable backwards compatibility. OTOH, if you're a consultant designing an application for a customer, you can be much more flexible depending on his/her upgradeability potential.

    With respect to non-core modules as dependencies, it's much more of a crapshoot. Approach #3 seems very reasonable there. Let CPAN users give you feedback if you're requiring too recent a version, then change it in your next upgrade. (I personally shy away from distributions that sit on a mountain of dependencies, but that's more of a personal taste.)

    And, of course, given the distributions you listed as examples, one should ask, "Do I need this module for my module's functionality, or simply to write a better test suite?" But that is for another thread (and has been!).


    Jim Keenan

      Great points, Jim. I've also been using Module::CoreList to help in my evaluations. For others interested in this, I've posted a quick and dirty script I've been using for this as a snippet: Find version of a module included in perl core.

      Sample output:


      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://484300]
Approved by BrowserUk
Front-paged by Tanktalus
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2017-04-30 21:18 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (542 votes). Check out past polls.