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.
In reply to Re: Help with PAUSE mechanics - replacing a bad module
by NERDVANA
in thread Help with PAUSE mechanics - replacing a bad module
by PUCKERING
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |