1st, Ill presume that whatever CPAN modules youre using will not be the problems; it will be your private/corporate code, which has never been tried on 5.8. A simple `perl -cw -Mdiagnostics -Myourmodule` will at least give you a quick look at how many lines you have to touch. Note that this is a poor estimate in any case; in 1 hr you can fix hundreds of syntax errors, theyre unlikely to contribute materially to the cost/risk of the porting project. In fact - you could fix the syntax errors faster than you could read all the changes and diagnostics.

You should review your current systems architecture with an eye towards understanding how to improve its testability;

if it has a DB, do you have a separate instance, and can you (easily, trivally, repeatedly) clone the production database into the dev/test DB ?

If you have lots of flat files, configs, etc, do you have relative paths that would allow you to swap back and forth between multiple setups ?

Id suggest that delaying a port will inevitably result in more work-arounds for things you could get for free - for everything that trips you up, there will be 10 or 20 bugfixes you dont have to find for yourself.

Bottom line, the effort will be dominated by factors we cant evaluate - do you have effective scaffolding which will allow you to fully test the new without interference with the old ?

Take a lesson from Perl. It has thousands of tests - no progress in enhancements or bugfixes would be possible without them.

Related to this, I've heard about (but not experienced personally) problems that arise if you are on a particular linux distro (Red Hat 8 for sure, maybe 9 too but I'm not sure) with a particular user environment involving the use of a "utf8 aware" locale, and you have scripts that handle any sort of unformatted-binary or wide-character data. Basically, given the "right" set of triggering conditions, a script that worked in 5.005 may fail in 5.8.0 with error reports about "malformed utf8 data", despite the fact that the script and data have nothing whatever to do with utf8.

If you use the PM "Super Search" for "utf8 error", you might get some tastes of the details (they are a bit arcane, and there are simple patches to make older scripts behave as intended, if this turns out to be a problem). Apart from that, I have found a few items in the Unicode support (a couple obscure regex problems and some of the conversions to/from non-unicode character sets) that aren't quite right in 5.8.0, and I'm eager to see 5.8.1 come out -- but this all has to do with stuff that 5.005 could never have touched in the first place.

In general, things that worked in 5.005 work fine in 5.8, and the transition does not involve complications. Of course, you'll be "re-installing" modules for 5.8 if they involve compilation -- don't just re-use the modules that were built for 5.005.

There is also my particular issue today, using pack():
http://www.perlmonks.com/index.pl?node_id=284198

And this one I just stumbled across:
http://www.perlmonks.com/index.pl?node_id=283932

I can't tell you any particular issues of which I am aware beyond unicode and whatnot. However, I can point you to what may be the best sources: perl56delta, perl561delta, perl570delta, perl571delta, perl572delta, and of course perldelta.

Hope this helps. Deepest apologies for the massive amount of reading suggestions.

antirice    
The first rule of Perl club is - use Perl
The ith rule of Perl club is - follow rule i - 1 for i > 1

Don't apologize -- massive amounts of reading are just what I was looking for. (I'm always happy to RTFM; I just occasionally need a pointer to the useful docs.)

Most things still worked. Many scripts gave minor warnings - something about // vs. "" in splits. A few larger problems.

Two options: Install 5.8 in a different path, or with a different executable name. Then run through all your scripts with /path/to/new/perl-5.8 -wc script.pl. Fix whatever errors exist. Most of it is minor stuff, so the fixes should still work in 5.005_03.

Option two: Just go for it. If nothing is very critical, just upgrade. Do the perl -wc tests on everything, and fix it as you go. Since it was a surprise, this is what I did. For a large repository of scripts here, it only took me an hour or two to fix everything. A few things broke, but most just gave extra warnings.

Good luck!
~Jon

As for issues... The major issue I can think of is related to UTF8. Indeed from 5.6.0 on, perl has native UTF-8 support. Sometimes perl will convert between what it thinks is ISO-Latin-1 and UTF-8, without you asking for it, or even where it is not what you want. It can, and will, happen when you concatenate normal strings, entered in Perl, with the output of XML::Parser.

You'll just have to test it. Make a new installation of perl, retaining the old one, next make a copy of your script that'll run under the new perl, and test it. Test it, test it, test it! All while keeping the old copy in place, of course, and making sure it'll chug along as before.

Ah, yes; "retain" was poor wording on my part.

It has many bugs fixed, including Unicode-related bugs.

In case you don't want to wait a bit, then it worth upgrading to 5.8.1-RC4, perl-5.8.0 isn't very stable, at least compared to 5.8.1-RC4

Courage, the Cowardly Dog

Well, rather than upgrade to 5.8, why not just upgrade to 5.6.1, since that has been stable for a long long time? (All be it that some of the cpan modules are now geared towards 5.8, but if the aim is for stability, we've been running 5.6.1 for a long time now with no problems.)

----
Zak

just because I do not understand upgrading from an old version to another old version: once you decided to upgrade and spend time and efforts for it, then it would be better to do this as good as possible, namely upgrade tp latest.

Yet 5.8.x much more feature-enabled version.

Unless you are into compiling your modules yourself, have a look at the Activestate Package Build Status to check and make sure that all the modules you require are available for 5.8.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law