-- Rob Nagler <[EMAIL PROTECTED]>
We are transitioning (slowly) between perl 5.005 and 5.6.1. Our trick
is to have separate 5.005 and 5.6.1 build/test (and sometimes dev)
machines. I'm not sure this solves your problem.
Simplest fix is to have two trees. One way to do this is take
everything in CVS and force it to, say, version 2.0. Any fixes
to 1.x are the 5.005 code; anything committed on the new tree
is 5.6.1. To look at new code just get the 2.X versions of
things; to patch the old stuff try 1.x. If you already have
2.X of some things take max(existing_version) + 1 for the new
version and go from there.
One quick way to deal with testing things is to tag the releases
with something meaningful and pass the tag to Q/A. They do an
update -d -P -r yourtag and test it. If things work then the update
gets run again in production and life goes on. Since nothing but
tagged releases go into production they can also back off easily if
a problem is found; ditto Q/A.
A daily automated build can be run using update -d -P and
a make test. If the make test passes in development then it
is tagged with "passed-YYYY-MM-DD". When enough fixes are in
the tag is forwarded to Q/A, who then do their update -r
with it. If that passes full testing on Q/A the tag becomes
a candidate for production -- which can use an update -r to
get the sources there.
enjoi
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
