NEILB's Blog

If you release a module to CPAN, and are hopeful that other modules on CPAN might use it, then it's good practice to specify the minimum version of Perl required to run your module. The other way of thinking about it: what's the oldest version of Perl your module supports? Here I'll discuss why you should do this, and how.

Following on from my previous post on CPAN terminology, this one focusses on the model and terminology related to dependencies: the modules that your dist uses, and the other CPAN distributions that use yours.

When using someone else's module in our CPAN modules, most of us don't bother to specify a minimum version of that module. If no-one else is using your module you can get away with that. But as your distribution moves up the CPAN River, you should start paying attention, and specify minimum versions both in the code and your distribution's metadata.

This blog post describes a model that we found useful for talking about CPAN dependencies and reverse dependencies at the QA Hackathon. At the head of the river is Perl itself with the core modules. The river flows into the sea, which contains all distributions that aren't used by any other distribution. Other distributions sit somewhere along the river, their position determined by their reverse dependencies. This post introduces the core concepts, but nothing more.

This blog post outlines an idea for a service that informs people when their CPAN distributions gain reverse dependencies. Many authors are probably not even aware that their distributions have reverse dependencies, and what the implications of that can be. Sending them an email gives us a chance to congratulate and engage authors, but also to educate and encourage them in some new practices.

This blog post outlines an idea for a service where people can register that they're using (i.e. dependent / reliant on) a CPAN distribution. This would provide additional information about which distributions underpin the Perl world, and if the registrants were contactable, it would help authors minimise breakages when making changes.

Two days ago I released Perl::MinimumVersion 1.36 to CPAN; there were two main commits that added checks for 3 changes in Perl. Both of those changes had bugs, and in doing so I broke things for other people, something I really didn't want to do. As a result I had to do a release tonight, to fix one of the bugs and back out the other until I can do it properly. I'm going to talk through how I've been working on Perl::MinimumVersion, the bugs, and what I'm going to change. Hopefully people might point out other ways I can improve how I work.

I've released the first version of CPAN::ReverseDependencies, which given the name of one CPAN distribution, will return a list of the names of other CPAN distributions that use it. This uses the MetaCPAN API, and is based on some code that I think I got from OALDERS.

As I described in a recent post, I discovered that my Module::Path module has rather more dependent distributions than I thought. Awareness of this has changed my behaviour, for the good.

While working on my adoption metric I've been looking at the number of distributions dependent on each distribution. Today I built the full dependency graph, so I could count the total number of dependencies. Or as ETHER put it: "how many other distributions will you break if you break yours?" It turns out 70% of CPAN distributions aren't used by any other distribution.