Do you know where your variables are? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Many excellent points have been made for your consideration. My personal habit is to intall the versioned binaries, and give people a few weeks warning of the upgrade so they can test. At the given date, I relink /usr/bin/perl to the new binary. Users can edit their own scripts either making whatever changes to migrate are required or changing their #! line to point to the about to be deprecated version. We keep our systemwide Perl programs in a single directory, which makes it a bit easier to copy the entire set, change the version they use, and test. Programs we want to deprecate we point to the old binary and don't bother testing. As for modules, the CPAN module provides a way to define your own bundle of modules available from CPAN. IIRC, this can even be done somewhat automtically. This can save a lot of effort on upgrades, since you can install your entire bundle from the latest versions directly off CPAN. I've generally opted for the more conservative approach of maintaining a directory where I store the tarballs of every Perl module I've installed on the system, so I can re-install the same versions as were currently in use into the new Perl versions tree. Best of luck! In reply to Re: Smooth perl upgrades
by spq
|
|