I would highly, highly recommend not doing that. Running your development and production boxes on different levels, that is. What if, for example, you triggered a perl memory corruption that has been fixed (common problem here)? So, if you're using perl 5.8.6 in development, you never see the problem. As soon as you put it in production on 5.8.0, bam!, core dump. Now you're scrambling to recover since your production server isn't working anymore.
Better to use the same level on both boxes, find the problem in development, and come up with a plan to get your software working in production. This can be a plan to upgrade the world to 5.8.1 or 5.8.6 or anything in between, or it can be a plan to try to not do whatever causes the memory corruption (e.g., don't use as many globs - I had that problem in 5.8.0, and this was my solution since 5.8.1 wasn't out yet). But it will be a plan, and one you can execute quickly with a reasonably well-known downtime for your production server. There will be fewer gotchas and surprises at the last minute - which is always a good thing. You can have all of management buy in to the plan. And they will be much happier with known issues than they will with unknowns that jump up and catch them. What if someone had a critical need for the production server you just took down 30 minutes after you took it down? By having a reasonable estimate of the affects of an upgrade, you can tell everyone that the server is going to be unavailable for that time period, and can negotiate a time for the upgrade that is appropriate, rather than surprising everyone with that crash.
Yes, I'm rambling. It's that important.
In reply to Re: Version-independent installation directories
by Tanktalus
in thread Version-independent installation directories
by sfink
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |