in reply to Help with PAUSE mechanics - replacing a bad module

While I also come from a background of preferring to do versioning differently than the perl standard, for CPAN I decided
When in Rome, do as the Romans do

The CPAN de-facto standard is that every version number is a float, and may or may not follow the v-string notation where minor number and release number occupy 3 decimal digits. Start with the major number at 0 until you have a more-or-less finalized API, and robust tests, then bump it to 1. Bump major when the API has a major change. Bump the minor for new features, and bump the release for misc bug fixes. If the long version number seems excessive, do what 50% of CPAN dists do and just roll the minor/release into a single 2-digit incrementing number like "0.45" and skip v-string entirely.

Regardless of numbering scheme, always write a change log that can be found and parsed by metacpan.org so that if someone cares about the release date, they can quickly jump into the change log and see what dates each version was released.

Only consider date-based versions if you have a module that is truly date-based, such as Mozilla::CA where the API has never changed and it is just a collection of official data files as-of a given date. Note that Mozilla::CA chose to write the entire date into the major version, rather than mess with minor/release numbers.

  • Comment on Re: Help with PAUSE mechanics - replacing a bad module