Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re: Arguements for upgrading from Perl 5.8

by sundialsvc4 (Abbot)
on Nov 18, 2011 at 01:13 UTC ( #938721=note: print w/replies, xml ) Need Help??

in reply to Arguements for upgrading from Perl 5.8

Step into your management’s shoes and attempt to construct a business cost/benefit/risk analysis.   This is a production system with over two hundred CPAN modules ... and exactly where is the overwhelming business justification to change anything?

I’m not saying that such a justification does not exist.

  • Comment on Re: Arguements for upgrading from Perl 5.8

Replies are listed 'Best First'.
Re^2: Arguements for upgrading from Perl 5.8
by chromatic (Archbishop) on Nov 18, 2011 at 07:46 UTC
    ... and exactly where is the overwhelming business justification to change anything?

    In my business, where I am the technical manager, it's very simple. We don't run unsupported versions of Perl. While we may never run into bugs in Perl that could block our business, the fact that we're never getting those bugs fixed in unsupported versions is a bigger risk than that of upgrading frequently.

    A blocker bug means we lose real dollars. Testing an upgrade means launching an automated process and, almost always, getting the green light to proceed.

    Certainly upgrading regularly has an upgrade tax, but in the case of Perl it's reasonably easy to test upgrades and deploy upgrades, and that tax is much, much less with a good process for upgrading regularly. Perl 5's predictable release and upgrade schedule, as well as the entire CPAN infrastructure, is immensely helpful.

    Improve your skills with Modern Perl: the free book.

      /me nods...

      And in my business, ditto, so do we.   After carefully weighing, for example, the potential impact to any system-management tools being used by a distro vendor. We often compile Perl from source, just the way we like it, and put it into /usr/local/bin.   We also deploy CPAN libraries into a /usr/local subdirectory and make sure that we are referencing it at the exclusion of any system-provided modules.   You have to maintain absolute jurisdiction over the entire environment that affects whatever you deploy, and every part of it has to be precisely reproducible in the test cases.   So, there is always a business necessity to be weighed, and a deployment and testing and maintenance plan to be drawn-up and so on.   It can be “quite the bit o’ busy-work,” actually...

      It’s really rather annoying, for lack of a better word, that the language-system versions used by many distros are routinely so old.   But they all build up quite an assortment of system management tools which are dependent on that stuff, and I know they don’t have too much of an alternative either.

Re^2: Arguements for upgrading from Perl 5.8
by Anonymous Monk on Nov 18, 2011 at 12:15 UTC

    However, an upgrade at some point is inevitable. The next Ubuntu server won't come with 5.8

    A separate install of a latest perl for one application allows you to do get things done at your own pace rather than when you upgrade the server. You can test your other applications one a time and be ready for the Ubuntu upgrade when it occurs.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://938721]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (9)
As of 2018-05-22 12:52 GMT
Find Nodes?
    Voting Booth?