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.

Perl Long Term Support and "The GreyPAN" 11 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I really like the Ubuntu model of designating certain releases as long-term support releases.

    If Perl were to release twice a year, then it could mark a release every 3 years or so as a long-term support release, and support it for maybe 5 years (the idea being you have 2 years from the _next_ LTS to upgrade).

    Feel free to tweak those numbers as needed, but I think the general idea is sound. Supporting every release for 8-10 years (or 5 years) is nuts. Supporting no release for longer than a year seems proble

    • Number of FTEs at SAP AG: over 51,000.

      Number of FTEs at Canonical, Ltd.: over 200.

      Number of FTEs maintaining Perl: 0.

      I should write in more detail what I'd like to see, but if I were in charge, I'd have yearly major releases. Perl 5.12 comes out in January 2010. There are three quarterly releases: Perl 5.12.1 in April, Perl 5.12.2 in July, and Perl 5.12.3 in October. p5p strongly encourages people to upgrade to the newest quarterly release, when possible. These quarterly releases only contain bugfixes.

      • The number of employees is largely irrelevant.

        It's an issue of what the market and users demand, and what (as a result) we feel will make them happier and more productive. Hence "support"...

        My point with the long timeline was that for the corporates, "Every 8-10 years, on a Saturday afternoon" is what they want. And it's these people that employ a whole lot of us, and in 5s and 10s and 20s at a time.

        It's all well and good to deprecate lots of things quickly, and move in different directions each year. But i

        • It's an issue of what the market and users demand....

          If businesses want something they're not getting from the Perl development process, they should do what we expect individuals who want something from the Perl development process: contribute something more than their desires.

          The number of employees is largely irrelevant.

          I'll give you one reason SAP software is expensive: it costs a lot to maintain software for a decade. Where are those resources in the Perl 5 world? They do not exist now. Where will they come from?

          I'd like to be a fly on the wall when you tell Nicholas or Dave or Rafael or Merijn that they need to multiply their workload because they're perfectly capable of maintaining several times the releases that they currently do.

          It's all well and good to deprecate lots of things quickly, and move in different directions each year.

          Are you arguing against something you thought I wrote? I never wrote that.

          ... if no feature that is added today can be trusted to stay around longer than a couple of years....

          Who are you responding to here? Did anyone seriously suggest that?

          ... one of the great reasons I've always been able to use for Perl/LAMP stacks against Microsoft stacks was that with Perl the language isn't going to be arbitrarily end-of-lifed every 2 years as something newer and shinier comes along.

          Ditto this.

          (One wonders how long knowledgeable Perl programmers will have to warn people not to use the Switch module, despite the fact that we've known it's been badly broken for several years, because we can't remove it until after a long -- unspecified in time -- deprecation process and because we can't suggest people upgrade to a modern release of Perl which supports a better version of the feature because it's not 2 pm on a Saturday in 2016 yet. That's... not exactly the way to produce the kind of reliable code I assume many businesses would like. Oh, and we can't predict if and when there will be a modern Perl release past 5.10.1 for these businesses not to upgrade to.)

          I'll repeat my argument, as there seems to be a lot of distortion in the transatlantic cable today. The Perl community has the resources, if not the will, to release a new major version of Perl 5 every year. The Perl community has the resources, if not the will, to release quarterly minor releases of Perl 5. The Perl community -- mostly in the form of the CPAN -- has never demonstrated the ability nor the desire to support software for multiple years, for free.

          • If businesses want something they're not getting from the Perl development process, they should do what we expect individuals who want something from the Perl development process: contribute something more than their desires.

            It seems to me that businesses who are using Perl currently are getting what they want. Versions of Perl start having real trouble when they are 5-10 years old. In over a decade as a Perl programmer I have never been targeting a production system with a version of Perl that was under

            • You don't have to release new versions of old software every 15 minutes to support it.

              I disagree with your arguments, but I take them seriously. Why don't mine deserve the same respect?

              • s/minutes/weeks/ or s/minutes/months/. Now can you bother honestly addressing the rest of the post?

                I suspect the real answer is "chromatic wants Perl to change quickly in XYZ ways; others want it to remain static in ABC ways; no one will convince anyone of anything." But this is just nerd-politics of the most pathetic sort.

                • Now can you bother honestly addressing the rest of the post?

                  What's the point? I've explained my point several times in several places. If people are still arguing against strawmen, no amount of logic on my part can possibly help.

                  Adam waves aside the point that sometimes work doesn't get done without people. I wonder how he explains that Perl 5 RCs do not get tested. (One rather suspects that SAP begs and pleads with very few of its 53,000+ employees to run through a test suite and a test matrix repres

                  • If you believe you have already explained, then a polite "I think I addressed that here" with a link only takes the same amount of time as a non-responsive response.

                    You "believe quarterly releases are achievable, useful, and far better than what we have now," but as a Perl user I kind of like what we have. My scripts keep running, and from time to time the interpreter gets a bit faster, memory leaks go away, and new features appear. Yes, I am anxious to use given/when and some of the new regex features, b

                  • Gnome managed to screw up session management big time, and Ubuntu (and FC10) packaged it. [livejournal.com] Clockwork release cycles can bring failure as well as success.

                    • I debated putting GNOME in that list; I disagree with some of its philosophies (gconf is no substitute for a working configuration dialog, for example) -- but overall I do believe it's better after a few regular releases.

                      Software isn't perfect. That's why we have followon releases.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.