Re^3: ALTernative solutions?

I commiserate.

I'd love to know what (kind of) organisation would mandate such a thing. And their reasoning.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^3: ALTernative solutions?

Replies are listed 'Best First'.
Re^4: ALTernative solutions? by ramlight (Friar) on Dec 19, 2011 at 19:18 UTC
I once worked on systems that were distributed to customers. Once a system was delivered to customers, upgrading Perl was no longer a possiblity. The in-house systems that had to mirror customer configurations were similarly held to the same version as field systems. So everything had to run (in this case) on 5.008. So there are the occasional instances where there is a valid reason to require older versions of Perl.	[reply]
Re^5: ALTernative solutions? by ww (Archbishop) on Dec 19, 2011 at 20:52 UTC
I don't see what you've described ("Once a system was delivered to customers, upgrading Perl was no longer a possiblity") as a basis for sticking to 5.005 (per OP, or 5.008 per current parent node?) in house. If the customer is paying for support on a system designed for an obsolte version; just give 'em notice; your firm will no longer support any version below (pick anything 5.10 or above would be my preference). If customer is NOT paying for support, TS on them. What are they gonna' do? Demand a refund on 13 year-old software?	[reply]