I advised starting at 0.01, 0.02, 0.03, ... and only when you've finally produced a stable, production quality API, on which users have come to depend, to indicate that by bumping the module version to 1.00.
This is precisely and exactly what I do. Generally any release before 1.00 has a note in the DESCRIPTION that the public API may change. Once I know the outside API will no longer change, I've got as close to or 100% test coverage, and the documentation is fully complete, I remove the warning and stamp it as 1.00, or the first stable version.
Sometimes getting to 1.00 takes only a few version bumps, others have taken me a few dozen, all depending on the complexity of the distribution in question.
In reply to Re^2: Help with PAUSE mechanics - replacing a bad module
by stevieb
in thread Help with PAUSE mechanics - replacing a bad module
by PUCKERING
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |