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 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 wil

          • 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, but I can wait.

                    I don't actually use any of the projects you list, so I can't say whether or not they have improved dramatically. The only software I use with semi-regular releases is probably MacOS/Cocoa, which seems to take backward compatibility very seriously. It offers significant changes/enhancements every 12-18 months.

                    Finally, I'm not worried about stability: I agree that if you keep a checked-in code base well-polished and -tested, you can roll releases quickly and therefore regularly. I think it would be both useful and doable for Perl 5 to do this for minor releases. My only beef is with regularly scheduled deprecation, which is entirely orthogonal. It's appropriate for many projects, but I don't believe Perl is one of them. You clearly disagree, because (I think) you have a different idea of what Perl should be. Chacun a son gout.