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 a year old. Only briefly have I dealt with one that was under 2 years old. I think I'm currently working with Perl 5.8.8. A few months ago I was targeting 5.8.6. And yes, I use CPAN. And have not encountered major issues.

            From this perspective I see what you've said about rapid deprecation and just shake my head. As much as you say that the Perl community doesn't have the resources to maintain old versions of software, as a practical matter the Perl community does an excellent job of keeping old software working. You don't have to release new versions of old software every 15 minutes to support it. You just need to keep the infrastructure that software depends on from changing out from under its feet. And my experience of the Perl community over the last decade says that it does an excellent job of doing just that.

            • 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.