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!).
HTH
Jim Keenan
In reply to Re: Which version to target for module dependencies?
by jkeenan1
in thread Which version to target for module dependencies?
by xdg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |