Actually this is not very reasonable at all, unless you have a different definition of production than I. The only sane way to run a production environment is a single version. You should always use the approach described in your second paragraph. Have as many versions as you want in a development environment, do your testing there, then roll the new version to production.
As for easy way out, you should never roll anything into production without a rollback plan. It would not be hard to devise several different rollback plans for this sort of upgrade. Ken Williams wrote: > It's quite reasonable to have multiple versions of perl in a > production environment, even though it may be a pain in the > ass. The main reason is for forward transition and backward > compatibility. If you've got 100 applications on a server, > chances are some of them are going to break when you upgrade > perl (more precisely, when the included modules change). So the > safest sane way to transition forward to new versions of perl is > to make sure that you keep the old & new versions separate, so > that applications can choose which one they're using, and then > "go live" with the updated versions when they've been properly > updated & tested in development. > > The alternative is to do all the testing & development in > advance on a development machine for all 100 applications so you > can upgrade them all at the same time, when you install the new > perl and blow away the old perl. And this doesn't give you an > easy way out if some application starts having unforeseen > problems, short of rolling back the entire upgrade.
