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.
  • I don't think chromatic is proposing that Perl start break back compat willy nilly. He's been quite clear that he wants to see Perl on a time-based release cycle with published deprecation schedules.

    Imagine if Perl release 4 times a year. Then if there was a desire to deprecate something, a release could say "feature X will be removed after 6 more releases, 18 months from now".

    That seems pretty reasonable.

    Furthermore, no one out there is jumping from 5.6 to 5.10 without some serious testing. Even with Perl'

    • I don't think chromatic is proposing that Perl start break back compat willy nilly. He's been quite clear that he wants to see Perl on a time-based release cycle with published deprecation schedules.

      Imagine if Perl release 4 times a year. Then if there was a desire to deprecate something, a release could say "feature X will be removed after 6 more releases, 18 months from now".

      That seems pretty reasonable.

      I don't disagree with anything you say. Heck, I agree with it.

      But

      I tried it. This is me. I have made m

      • I don't think your list is fair, Nicholas. I (and a few other Parrot developers) have a decent idea what it takes to make regular releases. We have over two years of experience doing just that. Parrot's not in the same stage of its lifecycle as Perl 5, but we've managed to reach a place where releasing a new version is very little fuss, comparatively speaking.

        There was a thread last year on p5p where several people volunteered to perform releases, provided that they could follow a brain-dead easy script

        • I don't think your list is fair, Nicholas. I (and a few other Parrot developers) have a decent idea what it takes to make regular releases.

          And it is a major reason that I no longer follow Parrot or Perl 6. It's too much trouble to keep up with the constant API and language changes. I'm often busy doing something else for a month or a year, and if I have to spend time fixing the working code you broke, I'll just do something else.

          • And it is a major reason that I no longer follow Parrot or Perl 6.

            That has nothing to do with regular releases and everything to do with the fact that no one has ever written Parrot or a full Perl 6 compiler before. If anyone could sit down and design completely such a system before writing any code, we'd have done so. Unfortunately, that's never possible for any system worth writing.

            • ...and that "full Perl 6" keeps changing, and that Parrot internals (PBC, PMCs, IMCC, etc.) do as well. If Perl 5 had regular bug-fixing and feature-adding releases, but kept its current level of stability and backward compatibility, that would be great. Regular Parrot-style "break-stuff" releases... not so much.

              Parrot/Rakudo/Perl6 is pre-alpha software. There's nothing wrong with that -- everything was pre-alpha at some point, and indeed pre-alpha projects can be fun -- but Parrot's being in that state places certain demands on developers, and makes it hard to build upon. The stability of things like libc, POSIX, and Perl 5 makes them easy to build upon, and making them unstable in the name of "modernity" undermines that value.