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

      • 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

    • One problem with this approach as being a "viable" upgrade cycle for deprecations is that you and I might upgrade regularly, incrementally and pay lots of attention to point releases, but businesses generally don't. They stay at 5.6.1 for many years and then gird themselves for a jump to 5.8.8. Thus, your nifty "four releases a year" means nothing to them. They don't dare upgrade their perl in parallel with those four releases (that would be very foolish of them), but they wait too long between releases

      • But those people will have the same problems with regular releases as they have now. Jumping from 5.6.1 to 5.8.8 (or 5.10.0) is a big deal with the current release system. If there were time-based releases, jumping across a huge number of releases will _still_ be a big deal.

        In both cases, you'll have to test all your code very carefully. You may also just give up and not upgrade.

        I've heard about Morgan Stanley's environment where the basically have apps deployed on every single version of Perl, and each app

    • Is "because fuck you a year from now" that much better than "because fuck you?" I like the way my Perl programs keep working when I copy them to a machine where the sysadmin has decided to install the "latest and greatest." The sysadmin likes the way I don't ask him to install an old Perl to un-break my working programs.

      • So you expect the Perl core folks instead to do all the work for you, and ensure that when you do something that's likely to be unsafe, it's safe anyway.

        That's ridiculous.

        • You missed "for free", "for longer than a decade", and "without seeing your code or even knowing that it exists."

        • The Perl core folks can do whatever they want (as if they need my permission!), but their emphasis on backward compatibility saves me a lot of headaches, and those saved headaches are part of why I keep using Perl. How hard is this to understand? I'm not making demands or threats; I'm just trying to explain why, in a world with too many programming languages, I continue to use Perl for day-to-day tasks.

          • [Their] emphasis on backward compatibility saves me a lot of headaches, and those saved headaches are part of why I keep using Perl.

            That same relentless emphasis on backward compatibility creates a lot of headaches, too. How many security holes exist because two-arg open still works? Why do I have to write the same boilerplate every time I start a new Perl program to ask the compiler for help? Why can't we have a class keyword? Why is the return value of system() inconsistent with the rest of Perl? W

            • How many security holes exist because two-arg open still works?

              I have no idea. How many of my programs are easier to use because it still works? This seems like the same attitude that led the GNU folks to put in a non-STFU-able linker warning about using gets. The C folks got it right when they made cc and lint separate programs -- assume the user know what he is doing, but let him ask for hints.

              Why do I have to write the same boilerplate every time I start a new Perl program to ask the compiler for hel

              • If you were Perl's sole author, this would be an off-putting but legitimate statement.

                My status as one of hundreds of contributors makes it no less a tautology: if you want absolutely nothing to change, don't upgrade. You can't have both.

                • if you want absolutely nothing to change

                  Where did I say this?

                  don't upgrade.

                  Where did I say that I am sysadmin on all the machines I use?

                  I may be a dirty pinko commie about the real world, but I'm a software conservative. If Bob Sysadmin upgrades Perl to version X, and Jim-Bob Sysadmin keeps it at Y on a different machine, it's a waste of my time to maintain two versions of my scripts... er, programs. Perl's (past?) sometimes-painful focus on backward compatibility and portability is one of its main featur

  • We find for our fairly large install (175k SLOC application, with 50 CPAN direct CPAN dependencies) that about 80% of the work required to upgrade is the same, regardless of how many Perl releases we jump across.