On Thursday, August 15, 2002, at 05:12 , Ken Williams wrote:
[..]
> The alternative is to do all the testing & development in advance on a
> development machine for all 100 applications so you can upgrade them all
> at the same time, when you install the new perl and blow away the old
> perl. And this doesn't give you an easy way out if some application
> starts having unforeseen problems, short of rolling back the entire
> upgrade.
[..]
painful, but true.
I guess a part of the problem I have here is that it
is not clear how the separation say
#!/usr/bin/perl is going to become 5.8
#!/usr/local/bin/perl is the older 5.6.1
that we get what you are suggesting, even less if
we try the
#!/usr/bin/env perl
and/or other variants.
I could imagine if the scripts were 'verbose' in themselves
by doing the actual assertion
#!/usr/bin/perl5.6.1 -w
use strict;
then when we 'roll forward' to /usr/bin/perl being a link
to /usr/bin/perl5.8.0 then all of the older "scripts"
would still be targetting ONLY the version of perl that
they had been committed to... since of course we would
adopt the 'standard'
#!/usr/bin/perl5.8.0 -w
use strict;
so that the scripts themselves define which rev they
are actually running....
Or am I missing how you were planning to do this 'cut over'????
ciao
drieux
---