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 to put everything in order. To my knowledge, no one who could put together that script took advantage of several willing volunteers. (For goodness' sake, though -- volunteers wrote a perldelta.)

        I realize that the bleed/stable branching model makes all of this difficult, and I realize that documenting the release process is not at all fun, and I realize that this work has a lot of little details and that capturing it all is not easy, but other projects have done it, successfully.

        You're still of course welcome to say that that's all too much talking and not enough action, but whatever happened to those volunteers? What was wrong with the plan that we all discussed?

        • 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 to put everything in order. To my knowledge, no one who could put together that script took advantage of several willing volunteers. (For goodness' sake, though -- volunteers wrote a perldelta.)

          Ah yes. This was my reply to that [mpe.mpg.de]. Several people, most of whom in their replies quoted my message that precisely what was needed was people who could follow the key part

          • I agree with all of that, with one caveat:

            Releases aren't that big a deal. There's a new release on the schedule. This one doesn't have to be perfect. It just has to be better than the previous one.

            We could discuss strategies for making releases much easier (getting rid of the blead/stable branches and making all features and integrations take place on git trees, getting smokes of those alternate trees, and pulling only when they're clean), but the first step is "Write down what it takes to make a releas

        • 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