I use a two-level strategy. I have a Production hierarchy with a PERL5LIB directory for local modules, and a bin directory for local executables (also used to pick and choose from various standard directories that a command might appear in). A Development directory has parallel directories containing only exceptions... the production directories also appear in the development PERL5LIB and search PATH, but following the development versions. So all the standard production stuff will work in the development hierarchy, but I can try out whatever combination of modules and commands I want in the development side. When I'm happy, I move the stuff from development to production.

updated I perhaps should add that I use a wrapper command on my "shebang" line.

perl there is just a symlink to a generic a.out that sets up my search PATH and PERL5LIB and assorted other project-specific environment variables, then execs the basename of the command by which it was invoked, perl, in this case, but make and your favorite shell are other useful commands to wrap, since they can profit from the environment variables set by the wrapper. The command to be executed usually appears in the bin directory the wrapper puts at the start of the PATH. This keeps all the environment manipulation out of the script, so the move from development to production involves nothing more than changing the shebang line. You can even try out a completely new version of perl in the development world, by linking to that version in the development-specific bin directory. But if you invoke any perl scripts that are still (only) in the production world, you would have to do so as perl script.pl rather than script.pl, to avoid the production-side wrapper. Truth be told, I usually rely on the good folks who give us perl to do all the hard work of ensuring backward compatibility. If I want to try out a new perl, I replace the link in the production bin to address the new perl. I can always change it back if something unsavory happens. The scripts themselves need not change at all, which makes the overhead of the wrapper worthwhile.