That argument makes no sense whatsoever.

At the point in time where a new application is developed & tested,i.e. pre-production; it is completely acceptable to use whatever CPAN modules that are available at that time, in the development of that application.

For existing applications, if you are adding new code to the codebase, regardless of whether that new code is developed totally in-house, or utilises one or more CPAN modules; you still have to go through the same, identical testing process.. The only time you avoid testing, is if you make no changes at all. And if you are making no changes, the subject of CPAN modules doesn't arise.

What you appear to be saying is that if you are developing a new application, and already have an existing one in production that uses some ancient version of Perl, and is so badly coded that you are scared to upgrade it, that your new application has to use that same ancient version of Perl. That's stupid.

It is entirely possible and practical to have multiple versions of Perl installed for different applications. Just don't add them to the path. Put the appropriate version of Perl into the application subtree and put a simple shell command into the path for each application that sets the path up for that application and invokes it.

Call it "loose coupling", "breaking dependency chains", or "application independence management". Avoiding locking your entire development effort into choices made and facilities available 5 or 10 years ago is the first thing on the curriculum of 'Business Application Management 101'.

It's the same lesson that was being learnt in corporate development shops in the mid '80s about getting locked into a single language or version of a compiler. Eventually, and sooner rather than later, the supplier of the compiler will drop support for the version you have selected as your 'one and only'. Or worse, the supplier will go bankrupt or be bought out and the compiler will simply become a zombie.

If each new development is made with the latest, stable, tested and certified version of whatever language/compiler makes sense for the project, when support for old versions is dropped, you only need to upgrade those projects that made use of that version--not your entire application suite.

You also get the side benefits of:

• Each project benefits from the latest technology.
• Each project can choose the language/compiler most appropriate to it's requirements.
• Each project can benefit from the availability of new third-party libraries that become available between projects.
• When the crunch comes 10 years from now and you are forced to upgrade projects that used tools that are no longer available or supported:
  1. Only one or two projects are affected each time.
  2. You don't find yourselves scrabbling around, paying premium prices for the very limited pool of programmers that have any residual expertise in that obsolete technology--at exactly the same time as every other company locked into it will be doing the same thing!.

I realise that companies are still making this mistake--in some cases for the third or fourth time in the last 30 years--, but if you have any influence whatsoever when the a new generation of bean-counters re-invent the "All new development will use version P.Q.R of language/compiler XYZ from now till doomsday (or the sh*t hits the fan)" directive; gently point out that 'doomsday' and 'the sh*t hitting the fan' are the same thing, and like all non-specific statutes of limitation, it always arrives sooner rather than later, and much sooner than their spreadsheet projections predict.

Actually, sod "gently", do it forcefully!