in reply to Sane deprecation policy for a CPAN module?

Thanks for asking this -- it reminded me I need to update Writing Solid CPAN Modules with advice on CPAN Module Versioning.

Short Summary

For a new module, start by adding the line:

our $VERSION = '0.01';
near the top of the file (shortly after the module's package statement). Note that our was introduced in Perl 5.6.0. If you need to support Perl versions earlier than that, use instead:
use vars qw($VERSION); $VERSION = '0.01';
With that done, simply bump up the value of $VERSION as you add new features; for example '0.01', '0.02', '0.03' and so on.

When you have finally produced a stable, production quality API, on which users have come to depend, it is a good idea to indicate that by bumping the module version to '1.00' or higher. And further to set your CPAN distribution's CPAN::Meta::Spec's release_status to "stable" (other values for this piece of CPAN distribution metadata are "testing" and "unstable").

General Software Versioning Refs

CPAN Versioning Refs

Other Refs

Note: apparently Perl Best Practices got this wrong (in Modules chapter, 221. Use three-part version numbers; 222. Enforce your version requirements programmatically) and so is a dubious reference on CPAN module versioning.

Some Perl Monks Versioning Nodes

META.yml and META.json

Deprecating a CPAN module

Judging the Quality of a CPAN module

TODO: Finish this section and point to it from "Dependencies" section of Writing Solid CPAN Modules

Warning signs:

Discouraged modules:

Note: Many updates were made long after the original reply - in preparation for later insertion into Writing Solid CPAN Modules

Replies are listed 'Best First'.
Re^2: Sane deprecation policy for a CPAN module?
by Dallaylaen (Chaplain) on Nov 19, 2018 at 04:42 UTC
    Well at least I got my version numbers right, apart from skipping x.y0 which I'm going to take up now.