Visualizing the Perl 5 support policy

By dagolden | Published: January 22, 2012

My last post showed historical Perl 5 release cycles, but comments I got on and off the blog suggested that my vaguely positive sentiments about the official support policy were misunderstood. This post expands and clarifies my view.

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.

Perl 5 Release Timeline (Amended)

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]

Posted in p5p, Uncategorized | Tagged , , , | Leave a comment

Visualizing Perl 5 release cycles

By dagolden | Published: January 20, 2012

Beginning with Perl 5, version 12, the Perl 5 language began an annual release cycle, with a new stable release around May of each year. Beginning with version 14, the Perl 5 maintainers also announced a formal support policy and ended support for version 10.

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.

Posted in p5p | Tagged , , , | 12 Comments

Perl Oasis 2012 wrapup

By dagolden | Published: January 17, 2012

Last weekend I attended the Orlando Perl Workshop. While the "hallway track" is one of the best parts of Perl workshops, the talks I saw were also excellent. Here is an overview of the sessions I attended.

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.

Posted in perl programming | Tagged , , , | 1 Comment

Yet another taint mode reminder

By dagolden | Published: October 4, 2011

Schwern just posted "How (not) To Load a Module..." that goes into great depth about the security risk in loading modules.

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.

Posted in perl programming | Tagged , , , | 11 Comments

How to find files with Path::Class::Rule

By dagolden | Published: September 13, 2011

Path::Class::Rule is what you get when you imagine the love-child of Path::Class and File::Find::Rule. Here is part of the SYNOPSIS:

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.

Posted in perl programming | Tagged , , | 6 Comments

© 2009-2012 David Golden All Rights Reserved