Acutally in some respects i would say that unless you have a definitive need for features in 5.8 then don't bother. Some tests ive seen show a drammatic slowdown from using 5.8 that if you arent using 5.8 specific features would suggest the upgrade is unnecessary.
I would also review perl delta and look for relevant stuff. File handling changed a lot, as did some aspects of hashing. Other than that I cant really help beyond saying that you should make warnings fatal and run your code for a while to see what happens.
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply] |
Why move? If you really need a feature of 5.8.x then fine. If not remember the old axiom: If it aint broken, don't fix it. As noted 5.8.x can benchmark a lot slower than 5.6.2 - as I understand it this is largely to do with all the unicode related internal changes.
Ideally you should have a full test suite so you can just put up 5.8.x, run the suite and relax. If not developing such a suite would be a good idea before you contemplate moving.
The major change to be aware of is binary incompatibility between 5.6.x and 5.8.x What this means is that every non (ActiveState) core C based module you have installed will need to be reinstalled before it has any chance of working. DBI, DBD::xxxx Digest::xxxx any many others fall into this category. Also you may need to have cl.exe handy as ActiveState no longer supplies PPMs for encryption modules so you may need to compile them yourself (unless you can find a PPM elsewhere)
| [reply] |
Seems like this is more about test planning than Perl, but that's OK by me...
demerphq has the right idea about groveling through the Perl delta and your own code, but there might be an easier way.
This'd be easier with a little more knowledge of the nature of the system under test, but I'll take a stab at two test methods you might consider. I'll assume (since it's Perl on Windows) that your production environment is small enough to be emulated in some way in a test environment.
The first approach: emulate your production environment in a test environment running 5.8. Duplicate the input to the production environment (or a subset of that input) and check for whatever's important: speed, data integrity, whatever.
The second approach: set up separate 5.6 and 5.8 test environments and send the same input through both environments. Compare the important stuff in each environment.
This kind of test planning is more art than science, but it may simply be enough to compare representative performance rather than plan particular tests. In any event, I for one am very interested in what you decide to do, and I hope to read more about your testing efforts.
Hope that helps... | [reply] |
Are you using DBD::Oracle? If so, fire up your favorite C compiler. ActiveState is no longer able to publish a ppm of DBD::Oracle so you will have to do it yourself.
More generally speaking, I've found the modules supplied by ActiveState to be inconsistent between releases. Thus, there is no garuntee (unless you have already looked) that all the modules you downloaded with 5.6.1 will be ready packed for 5.8.x. If you don't use ActiveState's PPM for module installation, then this won't matter to you.
So, if you have everything you need in your 5.6.1 environement, I would echo the advice of others and leave well enough alone...
| [reply] |
I really appreciate your input. I do need an updated DBI but no Perl 5.8 features at this time. Therefore I plan on moving to the 5.6.1 build. | [reply] |