Re: Help with PAUSE mechanics - replacing a bad module

> I recently published a new module on CPAN, starting off with a vanilla version number of 1.00

Well done for not starting with 1.0.0. :) CPAN versioning is something of a dark art, as I discovered when attempting to offer some general CPAN Module Versioning advice at:

Re: Sane deprecation policy for a CPAN module? (Software Versioning References)

In that node, 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. At least that seems the most popular approach in the Perl community. See that node's "CPAN Versioning Refs" section for why you should avoid a 1.2.3 versioning style.

> if I adopt a more sensible date-base versioning scheme, such as v1.22.242 (major version, year of century, day of year)

Why is this more sensible? Who endorses this scheme? Which well-known CPAN modules use it? Update: Re^2: Module version numbers best practice (meaning--) by tye cautions that using dates as version numbers runs into problems when trying to assign meaning to version numbers.

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

Replies are listed 'Best First'.

Re^2: Help with PAUSE mechanics - replacing a bad module
by stevieb (Canon) on Aug 31, 2022 at 16:12 UTC

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.

[reply]
[d/l]


No such thing as a small change
	PerlMonks