Writing version of dependencies

Sometimes excess laziness is not a virtue. Whenever I add a dependency, I used to just write in dist.ini:


This is of course not correct. Starting from last week, I've changed this habit. now I write the version which was currently installed on my development laptop/PC at the time of writing. And if I am not lazy, I try "cpanm Foo::Bar" first to update it to the latest version.


But do your users really need the same version of Foo::Bar as you have? Perhaps an earlier version of Foo::Bar will work just fine.

My usual technique is to specify version 0 of dependencies unless I'm aware of a particular case where it makes sense to require a higher version. For example, for MooseX stuff I generally depend on 2.00 because I know that a lot of the Moose internals changed between 1.x and 2.x. Or depend on XML::LibXML 1.70 because I want to use the load_xml method.

Yes, this occasionally results in CPAN testers failures, and/or bug reports. But then you just respond to the bug report with "upgrade to Foo::Bar version 0.61" and add that version to the dependencies of your next release.

If you're going to ship your module to CPAN, that might not be the best idea. Setting the minimum version to whatever is installed on your machine might force downstream users to upgrade things unnecessarily. It makes your life as a module maintainer easier, but it could make your users suffer.

My (ideal) strategy is to set the minimum version to zero until I know that there is some reason to require something newer. Then I rely on CPAN Testers to help me flesh that out. To minimize pain for users, I would first ship a development release. If the CPAN Testers don't find any dependency problems, then go ahead with a production release.

This strategy isn't foolproof. Some CPAN Testers always use a clean perl for each test, so they end up testing the latest versions of your dependencies anyway. It's also a lot of work to manage, and it's not fun to wait for test results before making a production release. So I don't always follow this strategy myself.

I'm hopeful that alpha.stratopan.com can somehow help with matching modules to the right version of their dependencies. But for now, it just keeps the dependencies for you -- it is up to you to decide which versions you want.


Hi Steven

Another approach is to use one of the scripts shipped with Module::Metadata::CoreList, which allows you to pick a version of Perl and get the matching version of a module which shipped with that Perl.

I flip flop on this. For awhile I did it your current way, but I got more complaints that way. Now I only set the minimum version if I know that I must have at least that version for a feature or bug fix.

I wish we had a way to have an undef version to mean that I don't know what it should be or I'm not specifying it.

I've been back and forth on this. Currently I specify whatever I use. That is to say if I use Foo; I specify dependency Foo => 0. If I use Foo 1.2; I specify Foo => 1.2. The use of a version is driven by bug fixes, features, and user feedback.

But I typically specify core dependencies as well. It is rare for modules to be dropped from core, but it is not unknown.

Once upon a time many years ago, declaring dependencies on core modules was problematic because CPAN.pm had a bug and might try to upgrade your perl. But that was then; the bug has been fixed roughly forever. You should never not declare a dependency, even if it is on a core module.

Leave a comment

About Steven Haryanto

user-pic A programmer (mostly Perl 5 nowadays). My CPAN ID: SHARYANTO. I'm sedusedan on perlmonks. My twitter is stevenharyanto (but I don't tweet much). Follow me on github: sharyanto.