NEILB's Blog

As part of the CPAN Report post I did recently, I looked at how recently distributions had their last release, and how that varied with the river position (number of dependent distributions). I've been playing with some other ideas related to this, to see if they'll help identify distributions that could do with some TLC.

At the QAH this year we had another discussion about the River of CPAN: what's been done since last year, and what we should do to keep things moving forward. These are the notes from that discussion, and some of the things that happened after the discussion.

In a series of previous posts ( 1, 2, 3 ) I had a look at some metrics for measuring the river quality of distributions. This post presents those metrics for the distributions at the head of the river: those distributions which have 10,000 downstream dependents or greater.

One of my goals for this year is to improve the water quality of the CPAN River, via a range of efforts, aimed at encouraging others to join in (eg the CPAN PRC), since there's only so much one person can do. To help measure this I'm coming up with various metrics. This one is simply looking at how the CPANTS Kwalitee varies across the different stages of the river.

How would you expect the number of open bugs / issues to vary as you look at distributions at different positions on the CPAN River? I expected the count to increase as you go up river, and it does. There, you don't need to read the rest of this post now :-)

One third of CPAN distributions (33.1%) have a github repository, but which distributions are they, and are distributions more likely to have a repo if they're further up the CPAN River? This is a quick post to record the stats for future comparison.

As a CPAN distribution moves up the river it needs to become more reliable, as by definition more distributions are relying on it. In this post I propose a simple metric for "suitability for depending on", which is essentially a water quality metric for the CPAN River.

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.