Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc

[davido]

For those authors who choose to do it this way, the following lines of code in a module will designate it as a "DEVELOPER'S RELEASE"

our $VERSION = '1.00_001'; # The underscore is the tip off.
$VERSION = eval $VERSION;

If I remember correctly how the mechanics work, the indexer sees the first version line by parsing the code itself. Then the version string is evaled to wipe away the underscore so that the number makes sense ...um... numerically.

This recommendation comes from perlmodstyle.

The effect of doing this is that the CPAN indexer won't index the tarball. It's still available for download from CPAN by specifying the path to the tarball, but the CPAN installers won't automatically install it when you just type, for example, "cpanm Module::Name". From the developer's standpoint, this is a win because the smoke testers still test the distribution. So he's able to get feedback from the smokers on multiple platforms and configurations without directly disturbing his users.

...that's if the developer uses this technique. I find it really useful for modules that are easy to break in ways that aren't obvious until a bunch of different smokers test them (Inline::CPP, and XS code, for example).

Update: I guess I forgot to finish that thought.

DEVELOPER RELEASEs are one flag from developers that the specific release is not production-ready. Aside from that, a few things I look for, in no particular order:

• Do I like the POD? The documentation is the first thing I see, and can demonstrate to me that the author has thought things through, or has just cobbled something together and thrown it up there.
• The bug RT queue; Are there longstanding bugs that haven't been addressed (and that make sense -- not all bug reports are actionable or realistic).
• The Changes, or ChangeLog file: Has activity mostly been bugfixes, or have there been a lot of sweeping changes? Do the comments in this file make me feel better or worse?
• What does the source code look like?
• How do the tests look? I mean the source code for the tests; a 100% PASS rate doesn't mean much if all that is being tested is "use_ok" (I've seen that!)
• How do the smoke test results look?
• Can I find code that depends on this module?
• Are there modern issues (such as the proliferation of Unicode) that have gone un-addressed by the module in the decade since it was written? Some modules require no adjustment as time passes. Others are sensitive to modernization issues. Those that are sensitive should be modernized.

[toolic]

You can even view test coverage for some modules.