Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^2: Why upgrade perl?

by vsespb (Hermit)
on May 20, 2013 at 13:38 UTC ( #1034340=note: print w/ replies, xml ) Need Help??


in reply to Re: Why upgrade perl?
in thread Why upgrade perl?

I think it's valid argument only if your applications are really huge or they're bloatware without testsuite, full of legacy code with 100+ CPAN dependencies and full of technical debt. And you're totally unsure why it would/wouldn't work on certain version of Perl.

Otherwise it will be pretty easy to test it with several versions of Perl, on dev machine, to make sure the code matches Perl specification, and that you are not using some crazy CPAN modules. Any incompatibility will be a good reason to investigate the reason to make sure your code actually does not contain bugs. Easier deploy to RHEL servers is a bonus


Comment on Re^2: Why upgrade perl?
Re^3: Why upgrade perl?
by MidLifeXis (Prior) on May 20, 2013 at 17:30 UTC

    Until your OS patch changes the OS's version of perl (or a library) under the hood, breaking the assumptions made by your application. This happens in large enough organizations where 'the canonical OS platform is X.Y.Z, and all machines must be upgraded to X.Y.Z by this and such date' (yes, it does happen :-/ ). Using your own perl gives one fewer moving part not under your control.

    If you are releasing on CPAN, then yes - test far and wide. There are times for both approaches.

    --MidLifeXis

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1034340]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (8)
As of 2014-11-22 21:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (124 votes), past polls