I have redone my Perl 5 release cycle graph again with a few changes. First, for the v5.4 through v5.8 series, I have broken the line to the final release, which I consider to be "outliers". I think the Perl community was lucky to get those releases — was lucky that someone stepped up and made them — and that they don't reflect a "normal development" or support cycle.

Second, I have projected an estimated lifecycle under the official support policy for v5.12, v5.14 and the not-yet-released v5.16. This represents an expectation for the normal support lifetime of these releases and I think shows a better contrast of expectations resulting from the support policy introduced with v5.14 compared to historical releases.

click for larger view

My observations (ignoring outliers):

• Prior to v5.14, there was a (sometimes lengthy) gap between the end of one stable series and the start of the next.
• The actively maintained periods of v5.4, v5.5 and v5.6 were shorter than the proposed support windows under the new policy
• v5.8 had two different support paradigms. Between v5.8.0 and v5.8.1 was a long gap similar to the v5.6 series. v5.8.1 to v5.8.8 had a more regularly-spaced series of support releases.
• v5.10 had the longest gap between initial release (v5.10.0) and the subsequent support release (v5.10.1)
• v5.12 has had the most consistent pattern of support releases after the initial release, and is the only stable Perl 5 to have a (regular, not outlier) support release after the release of the next stable version
• v5.14 was the first stable Perl 5 released under the new annual-release cycle

The new support policy most resembles a return to the best support period seen historically (v5.8.1 to v5.8.8), but without the subsequent gap to the next stable release.

Why do I think this new policy is a positive step forward? Here are some reasons:

• The support policy is actually written down. What expectations did anyone have prior? I don't know. But if I'm using Perl 5, I'd rather know what to expect that have to guess and hope for the best.
• The new policy offers a support window longer in practice than any Perl 5 except v5.8 and more regular than any period except between v5.8.1 and v5.8.8
• The new stable Perl 5 is available for migration testing mid-way through the support window of the prior stable release. If there are issues with migration, users can be confident of support for their existing version for an additional year (and emergency security support for a year after that).
• The annual release cycle means the change between one stable release and the next will be smaller, lowering migration risk

The new policy does cut off the "long tail" of expectations for an outlier release. I can understand that for some companies or OS packagers, a two-year support window (three for security) might feel too short, even if that is longer than was typically seen historically.

Here is where the annual stable release cycle and monthly development release cycle offer a huge side benefit: there is now a well-documented, frequently-used, regularly-updated release manager's guide for Perl 5. Now, the release process is so easy that a moderately-skilled Perl software engineer without much prior exposure to the Perl source repository can make a Perl 5 release tarball in about a day.

This means that even if the core Perl 5 development team isn't supporting, say, v5.12 anymore, a motivated company or community group could do the work necessary to prepare their own "outlier" release and either petition the Perl 5 core team to release it or could release their own stable "micro-fork" for others with long-term support needs. (There might even be a profitable business opportunity selling support for Perl versions past the official support window.)

Previously, Perl 5 development used to be bursty, with long delays between stable releases and with unclear expectations for support. Now, Perl 5 development happens like clockwork, and has a clear, written support policy.

[Note: this post represents my individual opinion and was not reviewed by the Perl 5 Porters core development team; it may or may not represent the views of other core developers; it is certainly not an "official" statement of the Perl 5 Porters in any way]

This is a significant change from the history of Perl, so I though it would be interesting to see how recent release cycles have compared to historic ones. The chart below shows releases over time since Perl 5, version 4 when releases were more officially split between "stable" and intermediate releases.

click for larger view

(Note: Starting with version 7, odd numbered versions were reserved for development releases and are omitted above. Versions 13 and 15 moved to a monthly release cycle for easier community testing of incremental development.)

I think the overall change to a shorter development cycle will benefit both users and maintainers of Perl 5. For users, each new release will be a smaller change from the previous, lowering upgrade risk, plus they can have confidence in an ongoing process of improvement. For maintainers, it avoids taking away effort from mainline development to retro-fit patches into a Perl that is many years old and might have substantially different guts.

Doing the Jitterbug

Jonathan Leto (dukeleto) presented Jitterbug, a cross language continuous integration tool for git (and written in Perl). It's a smaller, lighter tool than Jenkins, though it lacks distributed testing capabilities. It seems really good for small to medium sized Perl projects, as it already understands how to build and test things with a Makefile.PL or Build.PL. (see slides [pdf])

Javascript is Code

Jay Shirley (jshirley) gave a non-Perl talk that explained why Javascript tends in practice towards spaghetti code. He recommended the YUI3 framework and explained why it provides better structure and why it would be familiar to Perl programmers used to Moose.

A Brave New Perl World

Stevan Little (stevan) presented some ideas from the work-in-progress prototype of a meta-object protocol (aka MOP) for the Perl 5 core. I'm really excited by this and I think the design team is finding a pragmatic balance between power and simplicity.

Tweakers Anonymous

John Anderson (genehack) gave an editor-agnostic half-rant/half-tutorial about why and how to tweak your editor to be more productive and less repetitive. There were some good tips that I've already put intro practice, like teaching the editor to automatically "chmod +x" when saving any "*.pl" file. (see slides)

The First Thing Tak Did - Elegant Remote Control For Sysadmins

Matt S. Trout (mst) showed an insanely complicated but powerful command line tool to remotely execute any pure Perl code over ssh, without needing any prerequisite modules installed on the remote machine. It's worth exploring just to understand the magic that makes it work.

Game Development with Perl & SDL

Breno Oliveira (garu) gave a playful talk that showed how easy it has become to use Perl to write simple graphical games. In only a couple dozen lines of code, he demonstrated a simple 2D platform game using the built in physics model. (see slides)

Cooking Perl with Chef Solo

This was my talk, where I explained what I've been doing to make it possible to deploy Plack apps using Chef and Perlbrew and friends. (see slides)

Lightning talks

There was the usually assortment of amusing talks, though several presenters thought it would be "fun" to present their 20 minute (or longer) talks in 5 minutes for anyone who missed the original. (Note to future presenters -- please don't do that. Pick 5 key slides and just show those.)

The most interesting to me was the lightning talk by Bruce Gray (util), who introduced Rosetta Code, a site that shows how different languages solve hundreds of common programming problems. He said that Perl needs more solutions written to catch up to other languages, so if you have time and interest then please check it out.

Keynote

Cory Watson (gphat) gave a funny talk that in style was nearly worthy of Larry Wall. It meandered around the broad theme of "diversity" and whether more ways of thinking about things makes one smarter. It eventually circled back to Perl, but the overall call to action was to get out of the usual comfort zones and try something you haven't done before and aren't good at -- whether radical or minor -- in order to stretch your brain. (I can't do it justice in text -- I think you had to be there.)

Hackathon

On Sunday, I went for brunch with some other attendees and then parked myself at the hackathon until it was time to leave for the airport. While I was there, I sucessfully ported my auto-install CD creation tools to work on Debian ISOs instead of just Ubuntu ISOs, so I can test my Perl/Chef tools on that server platform as well.

Coda

As a final note, Chris Prather (perigrin) -- who appeared ably supported by his family -- put on an excellent conference and I want to thank him for the work that went into it. I hope I can attend again in 2013 and recommend it to anyone who wants to get away and have some fun with Perl in the dark of January.

The (not) funny thing is that none of what he's saying is a risk would be one when running in taint mode.

Consider "/tmp/foo.pm" with this:

package foo;
print "Loaded foo\n";
1;

Then consider this example of how Module::Load does something "unexpected":

$ perl -MModule::Load=load -wE 'my $file=shift; load $file' ::tmp::foo
Loaded foo

(The "threat" is that given an arbitrary module name to load, it will gladly load outside @INC.)

What if that was run under taint mode, instead?

$ perl -MModule::Load=load -wTE 'my $file=shift; load $file' ::tmp::foo
Insecure dependency in require while running with -T switch at /home/david/perl5/perlbrew/perls/perl-5.14.0/lib/5.14.0/Module/Load.pm line 27.
Insecure dependency in require while running with -T switch at /home/david/perl5/perlbrew/perls/perl-5.14.0/lib/5.14.0/Module/Load.pm line 27.

I'm not sure why that message is printed twice, but that was still a fatal error and foo.pm didn't load.

The moral of the story: if you incorporate arbitrary user input into your execution path, use taint mode and validate the input to make sure it's something safe.

use Path::Class::Rule;

my $rule = Path::Class::Rule->new; # match anything
$rule->file->size(">10k");         # add/chain rules

# iterator interface
my $next = $rule->iter( @dirs );
while ( my $file = $next->() ) {   # $file is a Path::Class object
  ...
}

As you can see, it has the same method-chaining of rule helpers that File::Find::Rule does. However, it's not built on top of File::Find, so you get a real, lazy iterator instead of the File::Find::Rule iterator that precomputes the results and hands them to you one at a time. The iterator returns Path::Class objects, which makes it a little easier to do some common file manipulations.

While Path::Class::Rule is very new, it already implements the following kinds of rule helpers:

• File name rules
• Directory skipping rules
• File test rules, e.g. -f, -d, -r, -w, etc.
• Stat test rules, e.g. results of stat()
• Search depth rules
• Perl file rules
• Version control file skipping rules

It's also easy to extend. You only need to "and" together a callback that gets $_ set to the Path::Class object under examination:

$rule->and( sub { -r -w -x $_ } ); # stacked filetest example

You can write extension classes with new helper methods using the add_helper method. Here's a simple example that matches files named "foo":

package Path::Class::Rule::Foo;

use Path::Class::Rule;

Path::Class::Rule->add_helper(
  foo => sub {
    my @args = @_; # do this to customize closure with arguments
    return sub {
      my ($item) = shift;
      return if $item->is_dir;
      return $item->basename =~ /^foo$/;
    }
  }
);

1;

If this module sounds interesting, give it a try! If you want to help improve it, fork it on Github and let me know what you have in mind.

(If you're a curmudgeon and want to know why I wrote another file-finding module for CPAN, read the "SEE ALSO" section of the documentation for my comparison to other things out there.)

Update I've released 0.004 with some additional SEE ALSO entries based on suggestions below.

I like that idea, and it inspired me to remind people to please also consider just giving "thanks", too.

Sure, I'd love a song or a small ebook (and maybe I should set up a wishlist), but I also love getting an email saying thanks, particularly when it is from someone I don't already know telling me that they like a module I released to CPAN or telling me how they are using my code to solve some problem they have. Email is cheap, but still has huge impact.

Perl is a community built on altruism. Don't forget to say thank you!

# from this
do_something()
  if condition();

# to this
if ( condition() ) {
  do_something();
}

I decided to automate that with a vim macro:

map ,if V:s/\(\s*\)  if \(.*\);/\1if (\2) {/<CR>kVdp>>$a;<CR><BS>}<CR><Esc>kkk^

For it to work, the if modifier has to be on a line of its own (which I usually do for code clarity) and the cursor needs to be on that line when running the macro.

Feel free to copy and adapt to your own needs and preferences.

Here are some options. See the last for a new way that I just cooked up and released to CPAN.

Use your favorite CPAN client against the current directory

Example:

$ cpan .

Beware that this also installs the module in the current directory, which may not be what you want.

cpanminus is smarter than that if you give it an option

$ cpanm --installdeps .

For Module::Build-based modules: Build installdeps

Example:

$ perl Build.PL
$ Build installdeps

For (some) Module::Install-based modules: make installdeps

Example:

$ perl Makefile.PL
$ make installdeps

Note that this requires the Makefile.PL to use the 'auto_install' plugin.

For Dist::Zilla-based modules: dzil listdeps

Example:

$ dzil listdeps | cpanm
# or
$ cpan $(dzil listdeps)

This requires installing Dist::Zilla any any dist.ini dependencies first:

$ cpanm Dist::Zilla
$ dzil authordeps | cpanm

(Notice a pattern here?)

Anything with Makefile.PL or Build.PL: MYMETA and mymeta-requires

Install the latest ExtUtils::MakeMaker, Module::Build and App::mymeta_requires. Then configure as usual and run 'mymeta-requires' to get a list of dependencies.

Example:

$ perl Makefile.PL
$ mymeta-requires | cpanm
# or
$ cpan $(mymeta-requires)

A nice feature of 'mymeta-requires' is that it gives you access to all the different prerequisite types defined in the CPAN::Meta::Spec. So if a module offers 'develop' prerequisites, you can include those like this:

$ mymeta-requires --develop | cpanm

See the documentation for other ways to control which prerequisites are included in the output.

One drawback is that you'll still need to install any configuration prerequisites needed to run Makefile.PL or Build.PL, but that is true of all other recipes above (except that ones that use a CPAN client).

Update: as of version 0.002, 'mymeta-requires' will fallback to a META.json|yml file and also picks up configuration prerequisites. So now you can bootstrap completely like this:

# get configuration prerequisites
$ mymeta-requires | cpanm

# run configuration
$ perl Makefile.PL

# get any additional dynamic prerequisites from configuration
$ mymeta-requires | cpanm

Easy!

I don't know what it would take to make that happen, because getting Alien packages right across platforms is tricky, but a first step is figuring out what libraries people wind up needing the most.

If you install libraries/headers by hand, what do you wind up using most often? Please answer in the comments.

Here's how I used Perl to rename these pictures into the right order based on the timestamp metadata inside the JPEG files:

#!/usr/bin/env perl
use 5.010;
use strict;
use warnings;
use autodie;
use Digest::MD5 'md5_hex';
use Image::ExifTool 'ImageInfo';
use Path::Class;

for my $f ( dir()->children ) {
  next if $f->is_dir;
  my $exif = Image::ExifTool->new;
  $exif->ExtractInfo($f->stringify);
  my $date = $exif->GetValue('DateTimeOriginal', 'PrintConv');
  next unless defined $date;
  $date =~ tr[ :][T-];
  my $digest = md5_hex($f->slurp);
  $digest = substr($digest,0,7);
  my $new_name = "$date-$digest.jpg";
  unless ( $f->basename eq $new_name ) {
    rename $f => $new_name;
    say "renamed $f => $new_name";
  }
}

This program renames everything in the current directory into a format like this "2011-05-28T14-48-20-7fc2e71.jpg" -- which is an ISO8601 datetime (with "-" instead of ":") plus the first 7-hex-characters of an MD5 checksum. I use the checksum on the off-chance that two pictures were taken at the exact same second (e.g. from two cameras) or that one picture was a cropped/retouched version of an original. Anything that doesn't have EXIF datetime information is skipped and then I have to examine those manually to sort them into the rest.

It's not much, but it's quick and it worked.