Re^2: Arguements for upgrading from Perl 5.8

[chromatic]

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

[sundialsvc4]

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