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