this gave me an idea, hard to do but i think its possible, to make a program that changes the old version script to a new one and tell the user what they need to make it run well. for example: lets say one have the next (very simple) script:
print "hello world\n"; our program will change it to: say "hello world"; and say to the user it needs at least version 5.10. i know its a lot of work, but that way if you upgrade your perl system you can make your programs rather easily workable instead of trying to find what you need to change to make it workable. since i am rather new to programing i would like to know if this is complete nonsense or just to much work or a great idea and so on. thanks, Moshe On Sun, Jan 9, 2011 at 9:20 PM, Gabor Szabo <[email protected]> wrote: > 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 >
_______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
