Visualizing Perl 5 release cycles

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.

This entry was posted in p5p and tagged , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.

13 Comments

  1. seano
    Posted January 20, 2012 at 2:13 pm | Permalink

    I understand how this is good for core developers, but it's actually a nuisance for Perl users, especially the much shorter support cycle. It's not so much that all the code I wrote for 5.10 or 5.8 is breaking because of 5.12 or 5.14 changes; it's that that the upgrade treadmill encourages CPAN authors to set arbitrary minimum versions on code that works on older Perls. Gah.

    • Posted January 20, 2012 at 3:12 pm | Permalink

      I've deleted my reply three times to try to make it sound less harsh, but I give up and here it goes: you're complaining that authors whose work you get to use for free prefer a newer Perl than you do. Dude... it's free and you benefit from it. Stop complaining.

      I work on lots of grotty Perl toolchain modules that have to work back to Perl 5.6 or so. I hate it. I much prefer to write to a modern Perl that has more features, fewer bugs, and lets me write more succinct and less-error-prone code.

    • Posted January 20, 2012 at 3:20 pm | Permalink

      > It's not so much that all the code I wrote for 5.10 or 5.8 is breaking because of 5.12 or 5.14 changes

      None of mine did. Can you reference the specific bug reports on rt.perl.org that caused a problem so we can consider how to avoid those in future?

      > it's that that the upgrade treadmill encourages CPAN authors to set arbitrary minimum versions on code that works on older Perls.

      Which distributions are you referring to? If you can give me the rt.cpan.org ticket numbers for the reports you filed explaining that they work fine I can make sure those are chased up and the minimums changed in the next release.

      -- mst

      • seano
        Posted January 20, 2012 at 3:47 pm | Permalink

        > Can you reference the specific bug reports on rt.perl.org that caused a problem so we can consider how to avoid those in future?

        I expressed myself poorly. I meant that almost none of my code had broken with newer Perls. I can think of two things off the top of my head: (1) testing for the existence of various *FOO{THING} without creating them in the process (e.g. "defined %foo" got deprecated and *FOO{SCALAR} is finicky); (2) changes in the way B::GV::STASH() behaves in 5.10. I wish this stuff had changed less, but it would be too much to expect of the porters to keep finicky and undocumented things like this constant.

        > If you can give me the rt.cpan.org ticket numbers for the reports you filed explaining that they work fine I can make sure those are chased up and the minimums changed in the next release.

        Seriously? I thought about putting in a ticket for Mojolicious (it claims to require 5.10.1, but is fine on 5.10.0), but assumed it would just be instantly rejected. I'd be happy to do so if I thought it had some chance of being applied.

        • Posted January 20, 2012 at 4:05 pm | Permalink

          Actually, it isn't fine on 5.10.0 at all - since Mojolicious now exports the 5.10 feature set, including ~~ and given/when by default, and that didn't function sanely on 5.10.0 (and is incompatible with the way it functions on 5.10.1+), code providing access to that feature set by default must depend on 5.10.1.

          I spoke to Sebastian Riedel for you, and he said he'd be happy to take a test patch that makes it clear the contract with the user is to export the *5.10.1+* version of the given/when and ~~ semantics by failing on 5.10.0 so that nobody else comes to the same misunderstanding you did.

          If you want pre-5.10.1 support you can use Catalyst, Dancer or Web::Simple, all of which still support 5.8.

          On the other hand, LWP now requires 5.8.8 and *I* have filed a ticket querying this since so far as I can tell it should still work fine on 5.8.5 - if you'd be interested in doing testing for that I'd love the help.

          -- mst

          • seano
            Posted January 21, 2012 at 4:38 am | Permalink

            > that didn't function sanely on 5.10.0 (and is incompatible with the way it functions on 5.10.1+), code providing access to that feature set by default must depend on 5.10.1.

            All of the code exercised by Mojolicious's tests apparently works under 5.10.0 semantics. IMHO only the simplest of smart-matches work in any sane way; if your code behaves differently under 5.10.0 and 5.10.1 semantics, it's using esoteric smart-matching. That said, users are always free to type "use Mojolicious; use feature ':5.12'", right?

            > I spoke to Sebastian Riedel for you, and he said he'd be happy to take a test patch that makes it clear the contract with the user is to export the *5.10.1+* version of the given/when and ~~ semantics by failing on 5.10.0 so that nobody else comes to the same misunderstanding you did.

            Thanks for taking the time, but the current situation seems more useful. All their tests still pass, so I'll just stick to the one-line local patch.

            Re LWP: I don't have 5.8.5 handy, but http://static.cpantesters.org/distro/L/libwww-perl.html seems to suggest that it still passes down to 5.4.

  2. seano
    Posted January 20, 2012 at 3:54 pm | Permalink

    First, thanks for keeping those grotty old modules working. A lot of old code uses them, and there's accumulated wisdom and experience among their cruft.

    > you're complaining that authors whose work you get to use for free prefer a newer Perl than you do

    No, I'm not. I'm saying that these people don't actually need that newer Perl. If they want to use newer features, or their tests break on an older Perl, they're welcome to go for it. But why make working code usable by less people by putting "use $VERSION" at the top? Other than for feature bundles, my philosophy is just to let people try the code on whatever version they want. If it breaks, the author has no obligation to fix the problems.

    • Posted January 20, 2012 at 4:09 pm | Permalink

      It's not always evident. I got a request to take out "use 5.010" but the requester didn't realize that I was using the "Q" flag in pack() which was only introduced then.

      As an author, I have to debate setting a minimum version by default to cover the range of code constructs I usually use, versus explicitly checking each time to see what minimum perl meets the features I actually used.

      The latter is best, but requires more effort and potentially whipsaws people. Maybe my code works fine on 5.8 and then in some release, I use "//" and then the minimum jumps to 5.10. Instead, by saying "5.10" I might be implicitly promising that I'm targeting that version and won't be changing it capriciously.

      I'm pretty open to a patch or a request if I can change a minimum without having to change how the code is written, but also I don't have a problem with authors targeting any minimum that makes their lives easier.

      • seano
        Posted January 21, 2012 at 4:47 am | Permalink

        > The latter is best, but requires more effort and potentially whipsaws people.

        I'd say let *them* check it. Then you can either backport it, ask them to provide a back-compatible patch, or add a version requirement.

        > I'm pretty open to a patch or a request if I can change a minimum without having to change how the code is written,

        As long as this is the case, I'm fine. But e.g. I remember trying to play with parsing some stuff with Marpa a few years ago on 5.8, submitting a patch to remove trivial uses of "given" and "//", and being blown off.

        I just wish authors would develop for whatever they had installed, without specifying a minimum (modulo "feature", of course), then bump up the minimum based on test results and bug reports.

        (And yes, to my shame, I should have written "usable by *fewer* people" in my previous post.)

  3. :m)
    Posted January 21, 2012 at 11:46 am | Permalink

    Excellent!
    There seems to be a gap between 5.10 and 5.12; is this on purpose?
    I think 5.10 is still supported, isn't it? (I have never understood how Perl distinguishes actively developed versions from "only" supported and deprecated versions. There is more than one way to see this, I guess?)
    Perhaps you could visualize this, too. :-)

    • Posted January 21, 2012 at 2:28 pm | Permalink

      I omitted the v5.9, v5.11, v5.13 and v5.15 development tracks, so you're only seeing part of the picture. v5.10 only had a two releases and the ".1" release took a long time after the ".0" release compared to earlier versions. Given how old v5.10 was at that point, energy went into the v5.11 series instead to prepare for v5.12 and the start of the annual release cycle.

      With the release of v5.14, official support for v5.10 ended. The new policy provides two years of official support for any stable release, plus an additional year of "critical security fixes only" support.

  4. Christian Walde
    Posted June 11, 2012 at 11:55 am | Permalink

    Think you could do an update for this now that 5.16 is out? :)

    • Posted June 12, 2012 at 9:49 am | Permalink

      I gave tsee the data for a YAPC presentation, so I don't want to steal his thunder. :-)

One Trackback

  • By Visualizing the Perl 5 support policy | David Golden on January 22, 2012 at 10:43 pm

    [...] Whatever comes to mind Skip to content About MeMy ProjectsMy TalksMy Code « Visualizing Perl 5 release cycles Visualizing the Perl 5 support policy By dagolden | Published: January 22, [...]

© 2009-2014 David Golden All Rights Reserved