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
- 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:
Exporter Refs
- Exporter - implements default import method for modules
- Exporter::Tiny by Toby Inkster - an exporter with the features of Sub::Exporter but only core dependencies
- Exporter::Shiny by Toby Inkster - shortcut for Exporter::Tiny
- Sub::Exporter by Ricardo Signes - a sophisticated exporter for custom-built routines
- Sub::Exporter::Tutorial by Ricardo Signes - a friendly guide to exporting with Sub::Exporter
META.yml and META.json
Some Perl Monks Versioning Nodes
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
Note: Many updates were made long after the original reply - in preparation for later insertion into Writing Solid CPAN Modules
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
|
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.