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).


    • 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, 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

        • by inkdroid (3294) on 2003.05.01 16:31 (#19693) Homepage Journal
          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 maintaining old versions could potentially be the straw that breaks the camels back. If upgrading is an issue in particular organizations (and I've been in one) then I think such organizations need to figure out why it is an issue, fix it, and move along. If they are worried about upgrading Perl then they'll be worried about upgrading other stuff too (OS, RDBMS, etc). Fear of upgrade is a paralyzing and incoherent sort of most fears are I suppose...

          If we don't start demonstrating that we can maintain two stable versions of Perl 5, then people are going to start thinking that Perl 5 is going to get abandoned within the next two years. It's very hard to make a case to a manager or customer for a Perl solution if they think that it will be unsupported (and hence they infer unsupportable) within the project's lifetime. Hence with the status quo we could find that Perl 6 is killing off Perl's future rather than ensuring it.

          Perl 5.8.0 was released while development of Perl 6 was going full steam ahead, so it looks to me (from the outside) that the uber Perl hackers are handling the situation well. But I guess you must see a different picture being on the inside of this process.