Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
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).

    -Dom

    • 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 [perl.org] of course.
      • 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 happen, but is not, is that bug fixes in 5.8.x could be merged back into the 5.6.x branch, and further releases made, staring with 5.6.2. This wouldn't have the new features added in 5.8.0, but would provide users of 5.6.1 who are hitting bugs with a solution. 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.

        There has been some history of continuing maintenance on more than one stable version simultaneously - for example 5.004_05 was released in April 1999, after 5.005_03. The fear I have is that your statement becomes "maintenance is only done on the latest stable release". Effectively we are now in such a situation - with the release of 5.8.0, activity on 5.6.x has ground to a halt.

        We keep saying that when Perl 6 comes out we are not going to abandon Perl 5 or its users, but judging from our current activity patterns that's exactly what we're going to do. Porting something from Perl 5 to Perl 6 is not going to be the same as tweaking it from Perl 5.6 to perl 5.8. 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.

        Please don't read me as anti-Perl 6 - I'm not. The internals of Perl 5 are becoming increasingly difficult to maintain, given all the things that have been bolted onto them (overloading, threads, UTF8, etc). They won't last - we need Perl 6. I'm just saying that we need to manage the transition carefully, and make it clear now that we will be able to, lest we scare people away to other languages

        • 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