Making Releases

Chapter 6 - Module Maintenance
by?Sam Tregar?
Apress ? 2002
has companion web siteCompanion Web Site

As Eric Raymond famously advised, "release early, release often."[12] There are a number of good reasons to follow his advice. Releases keep your user community engaged—users have a new release to download, test out, and critique. Frequent releases also mean that bugs have a shorter lifespan. If you hold onto bug fixes for long periods, you increase the chances that more people will run into the bug that's already fixed in your development tree.

Releasing real, working software is the most effective way to battle FUD[13] and head off competitors who might be close to a release themselves. Even in open source software, being the first to market has its benefits!

Finally, by releasing your module, you make it clear that your module is still being supported. It's unfortunate, but when people see that a module hasn't been updated in a few months they don't think "stable", they think "abandoned!"[14]

Stable and Development Releases

Despite all that good advice I just laid out, some of you aren't going to feel comfortable releasing a new version of your module with every new bug fix and feature. The reason usually is that you feel that your software should live up to a certain level of stability that requires long periods of testing to establish. This is laudable goal, and it doesn't have to be in conflict with the "release early, release often" credo.

In order to satisfy your need for stability while still reaping the benefits of frequent releases, you can divide your releases into frequent development releases and infrequent stable releases. CPAN even has support for this built in. If your version number ends with an underscore followed by numbers, CPAN won't index it for automatic download by the CPAN module. For example, say I make a stable release of Data::Counter version "1.2" and then I want to release a development version—if I give it the version number "1.2_01", CPAN won't index it for download. Then when users run the following command:

 $ perl -MCPAN -e 'install "Data::Counter"' 

they'll get the stable version. To get the development version, they'll have to download it directly from CPAN—the CPAN shell cannot be used to download development versions of modules.

Caution 

The only way to create a development version that CPAN will recognize as such is to append an underscore and a number to the version. It won't work to add words to the end; for example, "1.01_alpha" will get indexed as a normal release.

Be careful not to use making development releases as an excuse to put off stable releases indefinitely. This may sound obvious, but many open-source projects have been caught by this trap—even Perl itself, by some accounts. All your users deserve the fun of a new release, not just the thrill seekers!

Making Announcements

When you do issue a new release, you should make sure people hear about it. Write to mailing lists where potential users hang out. (As long as such partially off-topic posts are allowed—perl5-porters is a good example of a mailing list where you should not send your announcements.)

Many CPAN authors are in the bad habit of simply forwarding the acknowledgement e-mail from PAUSE to various mailing lists. This isn't much of an enticement to download unless you already happen to be a user of the module. I recommend you post a stripped-down version of your README along with download instructions and the most recent snippet of your change log. If you've included patches from other developers, be sure to list them in the announcement— crediting your contributors will help encourage them to keep contributing and might even inspire others to join their lauded company.

freshmeat

freshmeat is a Web site dedicated to collecting release announcements of open- source projects. Thousands of potential users read through the announcement list every day looking for new and interesting projects. Registering your modules at freshmeat is easy; just visit the site, which is at http://www.freshmeat.net, and read the instructions there.

Usenet

The comp.lang.perl.announce mailing list was set up specifically as a place to post announcements of Perl-related projects. Your CPAN modules, no matter how bizarre, certainly qualify.

[12]The Cathedral and The Bazaar, http://www.tuxedo.org/~esr/writings/cathedral-bazaar.

[13]FUD stands for Fear, Uncertainty, and Doubt. It is the result of announcing a new feature, but not releasing the code. Commercial software companies (most famously Microsoft) use this technique to prevent their customers and potential customers from jumping ship to a competing product.

[14]Mark-Jason Dominus, from an interview by the author via e-mail in the spring of 2002



Writing Perl Modules for CPAN
Writing Perl Modules for CPAN
ISBN: 159059018X
EAN: 2147483647
Year: 2002
Pages: 110
Authors: Sam Tregar

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net