Dominic Mitchell writes:
> How do you cope with the problem that perl has of running different
> versions of modules?
Actually, we have two problems. One problem is developing with
multiple versions and the other is what you mention, running
production systems.
Sometimes I might be in the middle of some big refactoring, and a
customer calls with a problem. I then do:
cd
mkdir src_bla
cd src_bla
cvs checkout perl/Bla perl/Bivio
where Bivio is our shared code. Then I set PERLLIB to
~/src_bla. We've got a bash command that allows me to switch the
configuration and PERLLIB as well. It's very easy to do.
Oh, and we *never* (almost :-) put code in programs. The programs
invoke a *.pm file's "main" so we can say bla-some-command and always
get the right version.
We solve the second problem by buying cheap machines which run Linux
just fine. (I just bought 4 x Dell 2300, 2 x Dell 1300, and 2 x white
box for $1800. $-) It just isn't worth my time trying to make two
sites work on the same machine, although we do this in a couple of
cases (e.g. www.bivio.biz and petshop.bivio.biz).
When two or more sites do share the same machine, we always run the
same version of the infrastructure. This avoids many problems,
e.g. running into defects twice and managing multiple versions. We
don't tag our CVS. We can backout changes with RPM. We do several
releases a week on active applications, and one release a week on
applications in "maintenance" mode.
One final reason to avoid multiple versions is with schema changes.
The more different database versions you have, the more confusing. On
bivio.com we upgraded the schema about 250 times in about two years.
It would have been impossible to keep the development, test, and
production if these three diverged too much.
Rob
