I have a question concerning best practices for CPAN as they affect me.

Note, please include my own email address in all replies since I'm not subscribed to this mailing list, thanks.

Due to various historical reasons I had until a few years ago considered CPAN a good distribution mechanism for both Perl modules as well as standalone documentation which didn't have any Perl code in it. Even with my documentation-only distros I followed typical CPAN practices of writing them as .pod files and giving them names that fit into the CPAN module namespace and giving each version uploaded to CPAN a distinct version number.

However, as various alternatives such as GitHub have matured I suspect that using CPAN to distribute documentation-only things is not that appropriate and that such things should go out on other channels.

My question for you is partly whether there is any other precedent than my own usage for putting tarballs on CPAN that contain only documentation, or whether everyone else has always used them for this with actual code.

My other question is what are best alternates for publishing documentation which regularly evolves and is versioned, because that documentation typically is specifications for software. By default I would assume simply having a GitHub repository is a complete solution, but I was wondering if there were any other good alternatives.

As such, from now on, assuming that's the best move, I would restrict what I distribute on CPAN to modules/code written in Perl (which come with documentation specific to them), and leave documentation-only projects elsewhere instead.

An example of such a thing that would move is a specification of a module that would have implementations in both Perl 5 and Perl 6 as well as other langauges, the parts that are agnostic to implementation.

-- Darren Duncan

Reply via email to