Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Are there that many really nasty bugs left in 5.6.1? Just curious, I've mostly movd to 5.8.0 myself (and am eagerly anticipating 5.8.1).


    • Re:Why? (Score:3, Informative)

      There may be bugs, but slightly more import for me are the compilation issues [].
    • I guess I'm confused why development on 5.6.X would continue after the release of 5.8.X ... Isn't development always done on the latest stable release? Apart from Schwern's genius [] of course.
      • Re:Why? (Score:2, Interesting)

        It's true that most new development is done on the newer versions, but nonetheless, it's important to fix bugs in the old releases and support them.

        I was just curious as to what needed to be fixed in 5.6.1...


        • Re:Why? (Score:2, Informative)

          what needed to be fixed in 5.6.1...

          Well it plain doesn't compile with gcc 3.1 []. I think that we should fix that for starters

          The patch needed is smalle, and a work around is trivial: perl -ni~ -we 'print unless /: </' x2p/makefile makefile

          Likewise 5.005_03 doesn't compile on FreeBSD, unless you know to Configure it with -Uusenm -Dlddlflags='-shared -L/usr/local/lib' -Dldflags='-Wl,-E -L/usr/local/lib'

          The knowledge exists - what we seem to be bad at is transferring it into releases on CPAN. And wh

          • I still don't really understand why effort should be spent bugfixing perl 5.6.* when stable is 5.8.0 ... Shouldn't people be encouraged to upgrade to 5.8.0 instead of waiting for a newer 5.6.*? I guess this is something I'm not grokking about the Perl development process. If volunteer time is short shouldn't the time people have to give be marshalled around a particular release? Je ne comprends pas.
      • Re:Why? (Score:2, Informative)

        Isn't development always done on the latest stable release?

        Development is always done on the development track, which branches from the latest major stable release. So current development is on 5.9.0, which branched from 5.8.0 at the time of 5.8.0's release. However, bug fixes are also made where possible to the development release, and then merged back into the stable branch(es). So the upcoming 5.8.1 release will fix bugs found in 5.8.0, and this fixes will have first been made to 5.9.0.

        What could happe

        • Currently if people report that they have found a bug in 5.6.1, often we on perl5-porters have to respond that it's a known bug, fixed in 5.8.0, but as there isn't likely to be a 5.6.2 release your only option to see the back of it is to upgrade to 5.8.0. For large organisations, or anyone trying to stabilise on a particular perl version, such as 5.005_0x or 5.6.x, upgrading is not a trivial option.

          I would argue that this is as it should be. I imagine Perl developers have enough work already, and maintai