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 ---