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';
[download]

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';
[download]

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

• Software versioning (wikipedia)
• SemVer (Semantic Versioning in Software Management)
• This node mentions "C++ as a Live at Head Language" talk by Titus Winters, which describes Google's real world experiences with library versioning in huge code bases and why SemVer proved inadequate for them.
• API Change Strategy
• Stack Exchange question

CPAN Versioning Refs

• perlmodinstall - Installing CPAN Modules
• CPAN::Meta::Spec by xdg - specification for CPAN distribution metadata, see especially release_status field (with values 'stable', 'testing', 'unstable').
• perlmodlib : see "Guidelines for Module Creation" section. From that section: "To be fully compatible with the Exporter and MakeMaker modules you should store your module's version number in a non-my package variable called $VERSION. This should be a positive floating point number with at least two digits after the decimal (i.e., hundredths, e.g, $VERSION = "0.01"). Don't use a "1.3.2" style version. See (Module Version Checking) in Exporter for details". From the "Version numbering" sub-section: "The most common CPAN version numbering scheme looks like this: 1.00, 1.10, 1.11, 1.20, 1.30, 1.31, 1.32".

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.

See also:

• Version numbers should be boring by David Golden
• VERSION confusion by chromatic at modern perl books
• A guide to versions in Perl by Grinzz
• version - CPAN version module by Leon Timmermans
• only - CPAN only module by Ingy
• Licensing META files on CPAN (perlmaven)

META.yml and META.json

• ExtUtils::MakeMaker
• Module::Build
• Module::Install
• Dist::Zilla (See also: Dist::Zilla::Tutorial, dist-zilla on github, and dzil.org)

Some Perl Monks Versioning Nodes

• Module version numbers best practice by hippo
• Re^2: Module version numbers best practice (meaning--) by tye (using dates as version numbers runs into the problems of trying to assign meanings to version numbers)
• Re: Module version numbers best practice by admiral_grinder (sync the version numbers of your CPAN package with the version that your entry module uses)
• Seeking thoughts on version numbers in modules by xdg (2004)
• Can't use three part version number for CPAN modules by arc_of_descent (2006) - advised to stay away from PBP version numbers
• What basic things should I know about versioning modules? by nysus (2017) - Note that our $VERSION = "1.23"; seems to be the most compatible with the various Perl tools that parse code to find information on modules (taken from this reply by haukex)
• $VERSION in module files by bliako (2020) - see Re: $VERSION in module files by haukex
• Re^11: Perl Contempt in My Workplace (2021) asks for meaning of version 1.0 and how to indicate whether a module is experimental vs supported and in production.

• How should I install different versions of a module?

Deprecating a CPAN module

• XML::XSH by choroba - There is a big warning right at the top "This module is deprecated, use XML::XSH2 instead".
• XML::XSH2 by choroba - This is the current one. Looking forward to XSH3, XSH4, XSH5, ... :)
• Hmmm, CPAN::Meta::Spec does not appear to have a Deprecated status, release_status has only "stable", "testing", "unstable".

Perl Monks Nodes Added Later

• Help with PAUSE mechanics - replacing a bad module by PUCKERING (Aug 2022)
• Modulino to report ip address changes by davies (Oct 2022)
• Unable to release modulino to CPAN by davies (Oct 2022)
• Choosing the right module by Bod (Oct 2022)

• Version Control - GitHub and CPAN by Bod (2023)
• Re: Deciding dependency versions by Tux (2023)

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

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.