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" 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Is it just me, or are "how often does a business upgrade?", and "how often are new versions released?" often completely unrelated in many corporate environments. If you have brittle code that uses deprecated features, you probably aren't even going to consider installing the latest and greatest whenever it comes out.

    If perl is releasing every quarter or annually, all the people that are running 5.005 aren't going to care and are going to continue to running 5.005. Those people aren't going to upgrade until the HAVE to.

    I have to agree with autarch too, the Ubuntu model would make a lot of sense, and fit well somewhere between what chromatic and Alias are proposing.

    • If you have brittle code that uses deprecated features, you probably aren't even going to consider installing the latest and greatest whenever it comes out.

      Exactly.

      Those people aren't going to upgrade until [they] HAVE to.

      Exactly. Where are they getting support now? Not from p5p nor from the CPAN, and likely not from any core contributor. I completely fail to understand that mindset that it is the responsibility of anyone who wants to contribute a patch to the Perl core or upload a module to the CPAN

      • > Where are they getting support now?

        In the case of where I'm working now (medium-large corporate) we don't get to choose our Perl version anyway.

        Perl is an integral part of the underlying OS (RedHat) and while we may layer our own /opt/cpan modules on top of that, we are bound by that.

        One of the recent bugs in RedHat that they fixed was due to us invoking our support contract with them and having them fix the bug, because we needed it.

        I imagine a lot of other people are in the same situation. I'd have f

        • Perl is an integral part of the underlying OS ([Red Hat]) and while we may layer our own /opt/cpan modules on top of that, we are bound by that.

          Red Hat's FTE: 2200.

          Perl 5's FTE: still 0.

          If Red Hat wants to support Perl 5.6.x, that's Red Hat's business. I still fail to see how that obligates p5p to support Perl 5.6.x.

          • They aren't supporting 5.6, they're supporting 5.8.8.

            But by your timeline there could easily be things in 5.8.8 that have been deprecated by now.

            • They aren't supporting 5.6, they're supporting 5.8.8.

              Are they? I've see no communication in recent years from them about Perl 5.anything in RHEL. (As distinct from Fedora, where Redhat employee(s) working on it have been most communicative and helpful. I've no idea whether the same employees have Red hats as well as Fedora hats, in which case my question is probably unfair, as it could well be that by the time it comes to build a new RHEL from a Fedora, they've ironed out all their problems and simply don'

            • But by your timeline there could easily be things in 5.8.8 that have been deprecated by now.

              Yeah, wouldn't it be nice someday to have an XS that mere mortals can understand and use, with actual encapsulation such that perturbations in Perl's darkest guts don't break the code?

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