On Friday, August 16, 2002, at 12:00 PM, Rich & Michaela wrote: > 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.
Why? I've described a scenario where it's not true: when you have lots of applications on the same production server, and you can't afford to roll their versions forward all at the same time. > 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. Easier said than done. What happens if you discover a bug (or a business opportunity) that requires you to roll forward a new version of perl for a specific application in a short amount of time? If you have to wait for testing a bunch of unrelated side effects, it's going to be a huge lost opportunity or prolonged vulnerability. > 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. I agree, rollback plans are essential in each case. My point was that a rollback plan is much easier in my scenario, because you just roll back the single application. In your scenario, you'd have to roll back all applications, and perl itself, with all its module differences. -Ken
