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 more releases of Perl 5 than anyone using this site.

      I tried making regular, 3 monthly, releases of Perl 5.8.x. As a volunteer, I couldn't sustain it. I see a lot of people saying "wouldn't it be nice", and

      • none of them actually know what is involved as is,
      • none have actually suggested ways to make it viable, such that people not as good, not as dedicated as me stand better than a snowball's chance in hell of survivial,
      • none of them even ask "what could I do to help?"

      and until there are people putting even one tenth of their money where their mouth is, please, everyone, do not be surprised if nothing changes.

      (And no, this is not meant to be a personal criticism of anyone, let alone the person we all have to thank for DateTime, a most useful part of CPAN. It is merely that the most logical place to thread my opinion in, is in reply to his message)

      • Yeah, clearly the problem isn't (just) a lack of will. I'm not a Perl 5 core dev, so obviously I don't know all the details.

        So why couldn't you sustain it? Is there some reason preparing a release is so much work? How do Gnome and Ubuntu and other projects do it? More people? More money?

        One thing I have wondered is why we can't get a few paid people working on Perl 5. You'd think that there are enough companies out there depending on it that they'd be willing to kick in $10,000 per year each to TPF, and TPF

        • Yeah, clearly the problem isn't (just) a lack of will. I'm not a Perl 5 core dev, so obviously I don't know all the details.

          So why couldn't you sustain it? Is there some reason preparing a release is so much work?

          There was a long thread on p5p about regular releases for perl. I think this message is a good point to start reading (if I remember correctly): http://markmail.org/message/w4zbguq4cjitfvcb [markmail.org]

          One thing I have wondered is why we can't get a few paid people working on Perl 5. You'd think that there are enough companies out there depending on it that they'd be willing to kick in $10,000 per year each to TPF, and TPF in turn could hire a couple people.

          It would be great if companies would give some money to TPF. If you look at the donations page [perlfoundation.org] of the perlfoundation site, you'll see that there are not that many big donations (I know that booking.com gave $50,000 to TPF last year [hsyndicate.org] - thanks! But such donations are rare).
          Nevertheless TPF gave a grant to Dave Mitchell fo [perlfoundation.org]

      • 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

        • 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

      • I've been watching how some other projects manage this kind of stuff, and I have a few thoughts.

        First, you were doing maint releases, and backporting from dev into maint. I dont think that many projects have high frequency maint releases, in most projects maint releases are instead "just enough for the release to not be a problem" and only made as absolutely necessary. If a project has high frequency releases its at the bleading edge not in maint.

        Second, IMO backporting from dev to maint AT ALL only makes

        • Answering the easy bit:

          Would I be correct in thinking that leaving the quality of the latest blead aside that to release 5.11.1 is a matter of creating a tag, rolling and uploading a CPAN bundle and sending out an email?

          No, not just that. What really distinguishes a release from a mere developer snapshot is that a release has a perldelta file - a summary of the changes between the previous release and this release.

          (And what distinguishes a maintenance release from a developer release is that in a maintenan