> I thought the "min perl version" is a tough metric without considering what > version of Perl it will actually run on. I would refine that metric to > "declared min perl version >= actual perl version required". Figuring out > the latter could perhaps be done via CPAN Testers -- if all of 5.6 fails, > then we know it's 5.8 or better. But if there is at least one 5.6 pass, > then it works on 5.6. And if it works on 5.6, I think omission of a > minimum perl version is no big deal.
I nearly didn’t include the “min perl version” in this, as there’s no easy clean definition. As you say, using in conjunction with CPAN Testers results might produce something usable. The thing that prompted me to include it was the part of my talk about the fact that the OSes and versions of perl supported by your dist is the intersection of those your code supports and those supported by all of your upstream dependencies. Once we’re past the important events of the next few days[*], I’ll have more time to spend on this. > I don't want to see go down the Kwalitee route where people put a minimum > perl version of "5" or something just to get a better water quality score. Indeed. > Generally, I think some subset of the core Kwalitee metrics and some > adaptation of your adoption criteria (e.g. time since any release by author) > would be a place to look for "water quality" metrics. I do think you need to > find a way to distinguish what water quality is trying to measure distinct > from Kwalitee. Agreed. Part of my motivation for a separate and simpler measure was the feedback I had on the PR challenge, where some authors weren’t happy to get PRs that addressed failing CPANTS metrics. In general the message I got was “I agreed with some parts of kwalitee, but not other bits”. I’m hoping we can identify a small set of metrics that are hard to argue with when considering distributions that start moving up river. Neil [*] for example, taking my son to Star Wars tomorrow :-)
