On Sat, Jan 8, 2011 at 12:06 PM, David Baird <[email protected]> wrote: > Gabor, > > The most difficult question to answer to any management or policy > maker about migrating to a newer version of Perl is, "What new > features of Perl do you require to get your work done?" In answering > this question, one must respond to the word, "require" and not get in > the trap of "nice to have". Also, in many cases, it is not just > "required" for your job, but also for 5,000 other engineers that may > also have to upgrade to the new version of Perl if you do, too. >
I've just encountered this in a company where I am teaching. They are using ActivePerl 5.6.1 on Windows. Some engineers needed a module they did not have yet but it caused all kinds of problems: - ActiveState have discontinued the support of 5.6.1 so the ppd-s are not available any more. - We tried to configure the CPAN client but it had various issues and the machine does not have the necessary toolchain. I think we could not even configure gunzip. Most certainly we did not have a C compiler to install some of the C-using dependencies. - One of the dependencies was a dual life modue (File::Path or similar) and our new module required an upgrade. So by installing this new module we effectively changed the existing installed system. Silently and without checking any of the other pieces of code. So we might have broken existing systems. It would have been much better if there was a controlled way to upgrade all the systems. - The problem we did not encounter this time was having a dependency that requires a newer version of perl. So maybe you don't require any new feature of perl but you do need CPAN modules that are available less and less for your version of perl. You also waste more and more time on trying to use the old version. I think it might be interesting to create a report about "what do you miss if you only have perl 5.6.x" listing all the modules that depend on newer versions of perl. The funny thing is that they could install Strawberry Perl 5.10 in a separate path. Use that for the newer scripts and slowly move over all the other scripts. This time requering a better standard of perl coding. Maybe a central version control repository for scripts so there won't be unknown scripts running around. regards Gabor _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
