Typing away merrily, John Haggerty produced the immortal words: > Then you could have the solution of say changing the name of the package > to perhaps reflect that in fact you have perl4 or something and just > install incremental upgrades for the packages that aren't prone to > breakage. Eventually as people upgrade their stuff. You could slowly > retire the old stuff while supporting the new.
Erm, as I understand what I wrote, that's part of what I said: > If you have, eg, /bin/perl5.005_03 etc within the customer-facing root > and maintain those properly, you can introduce new versions and allow > the customers to manage the migration themselves; if you want to be able > to retire older versions which are broken, make sure that the customer > is aware of this fact and that they agree to a time-limit for phasing > out older versions (contracts time again). >From the Date: header in your mail, I see that it's still morning there. Monday-morning. This explains a lot. :^) Another coffee? (Note that I also warned about libperl - we recently got caught by this, more than once. The best solution seems to be static compilation of perl. Forcing perl to be entirely static is apparently not as straight-forward as it should be; I don't know, though, as a couple of colleagues handled this) -- HTML email - just say no --> Phil Pennock "We've got a patent on the conquering of a country through the use of force. We believe in world peace through extortionate license fees." -Bluemeat
