If it are old perl scripts (rather than modules written with a full and complete test suite), the only way to make sure they run, is by trying to run them.Set up a modern Perl system on a separate PC, mimic your production environment on that machine but make sure your scripts cannot access the real production environment (e.g. mission critical databases and such) and start the scripts. Feed it the data it need and if the scripts run to completion without dieing, check its output (messages, files, changes to the databases, ...). If all of that checks out fine, you can be reasonably certain that upgrading Perl did not cause major problems.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James My blog: Imperial Deltronics
</dive | [reply]
[d/l] |
| [reply] |
In addition to the previous good advice you could decide to accommodate the opposite: leave old modules for your scripts and only for them. You can do this pretty easily with Carton. You'd create a cpanfile for the scripts specifying the versions you want to freeze and then run things with carton. I don't have much experience with the package but the author is known for hits.
A full test suite is the real answer when you have the time or want something to last. Freezing at known working versions is a fine way to handle especially legacy code but it freezes out bug fixes and improvements as well as accidental breakage.
| [reply]
[d/l] |
In addition to the advice above, you may find PerlBrew to be helpful in this situation.
One code many Perl's is darn handy for testing... though honestly, I have never tried installinig a previous version of a Perl
module with it. Pretty easy to simply enter 'perlbrew use (perl version)' and run your code.
Just a thought...
...the majority is always wrong, and always the last to know about it...
Insanity: Doing the same thing over and over again and expecting different results...
A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct
| [reply] |
This is the fourth time you have posted this question (primarily 1087792; 1087794 and 1087796 reaped as dupes). Did you read the answers you got there? Did you take any of the advice? What worked and what didn't work? What has changed in the last month?
| [reply] |
Hum, you are right and I upvoted your post, but at the same time, it is quite possible that the OP did not understand the way PM works (and this is less than obvious for a first-time poster).
| [reply] |
There are really two possible scenarios here: did the packages in question change over time, or not? Are the features which these scripts use still active, or have they been deprecated by something else? This really is a subject of research, for which there is no automated answer.
Most commonly, packages are designed with forward-compatibility in mind, and they do run without incident. Therefore, I do generally suggest that you should keep up-to-date on packages ... not just for the ones that an application directly uses, but all of their co-requisites, as well.
You must have a sensible test-environment, though, and a test-plan. Making changes to a production environment is not a trivial undertaking. You must have both a rollout plan and a rollback plan.
| [reply] |