Re^2: Why upgrade perl?

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?

Replies are listed 'Best First'.
Re^3: Why upgrade perl? by MidLifeXis (Monsignor) 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	[reply]

Replies are listed 'Best First'.

Re^3: Why upgrade perl?
by MidLifeXis (Monsignor) 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

[reply]

In Section Seekers of Perl Wisdom