On 18 June 2011 12:34, Rob Kinyon <rob.kin...@gmail.com> wrote: > Uprgrading perl versions can require OS upgrades if your sysadmins say so. > It can also require significant testing burden because code optimized to 5.8 > doesn't run cleanly under 5.10 or above. And then there is the question of > modperl 1 vs modperl 2 vs fastcgi and module deps. I have seen 12 month > efforts to upgrade. It is not that simple.
Changing from modperl to FastCGI or from modperl 1 -> 2 is outside the scope of upgrading your Perl version.. Yes, that's going to add time, but you aren't forced to do those things when upgrading your core Perl to a newer version. If your sysadmins insist you upgrade the entire OS in order to upgrade Perl, well, that's another problem. They don't *have* to do that - if they choose to insist, then you can't blame the extra time required on Perl.. As for performance - I am yet to see any real-world code that runs slower on 5.12 or 5.14 (or 5.10) compared to 5.8. If you have some, I'm curious to see it.. I take it you've run into some yourself? I agree with your overall message though.. In large, locked-down corporate environments it can take a long time to migrate from an old to new version of Perl, due to all the roadblocks in the way, and because in the process you will almost certainly end up upgrading a bunch of other things at the same time. Cheers, Toby > On Jun 17, 2011, at 2:53, Toby Corkindale <t...@dryft.net> wrote: > >> On 14 June 2011 22:40, Peter Rabbitson <rabbit+d...@rabbit.us> wrote: >>> Toby Corkindale wrote: >>>> On 9 June 2011 17:51, Jorge Gonzalez <jorge.gonza...@daikon.es> wrote: >>>>> BTW, thanks for resurrecting a 3 month old thread :-) I had not checked >>>>> the EOL status of 5.8 and 5.10. And then again: RHEL 6 is based on 5.10, >>>>> which is also EOL'ed...? >>>> >>>> Yes, only the current and prior-to-current versions are supported by >>>> the Perl developers. >>>> So it'll be up to Red Hat themselves to patch any problems in 5.10 if >>>> they turn up. >>> >>> Just a note that by "perl developers" you (I hope) mean the >>> perl5-porters. Individual perl projects can and do elect to support >>> a much wider range of available perl binaries. For example DBIC >>> is currently supported all the way back to 5.8.1, and there are no >>> near-future plans to change this. >> >> Ah, sorry if that wasn't clear - yes, I meant the "Perl core" >> developers, not the DBIx::Class developers. >> >> BTW, I have a hard time believing that anyone who is still stuck on >> something antique like Perl 5.8.1 would be allowed to use latest >> versions of DBIx::Class. >> >> _______________________________________________ >> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class >> IRC: irc.perl.org#dbix-class >> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ >> Searchable Archive: >> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk > > _______________________________________________ > List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class > IRC: irc.perl.org#dbix-class > SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ > Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk > -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk