It's uncommon that pure-Perl code that does common things within the mainstream of the language on common platforms would break after an upgrade. There are things that can cause some breakage, though. I'll stick to the convention here of "Perl" meaning the language and "perl" meaning the executable to avoid repeating distinctions over and over.
Things can seem broken when using modules with some portion of them written in C that are compiled against a version of perl that is not binary compatible. Binary incompatibilities can be caused by differences in the data structures of perl between versions. They can also be caused when different compilers were used to build perl and the module in question. The happens with any compiled language when libraries get out of sync, but people often overlook it for Perl. I think that's since the main application logic is usually fed to perl as source.
This is fixed by compiling the module against the newer perl or getting a copy that has been.
Programs that used barewords that are now reserved by Perl or that are suddenly methods of a class or object that's in use can break things. Following best practices this should definitely be rare, but it could happen in legacy code.
This is fixed by taking out the offending barewords and making them properly quoted strings, proper function calls, or proper direct object notation, whichever fits.
Modules on CPAN may get bugs when they are updated. There's no mandatory formal pre-release test enforced by CPAN itself. The authors and maintainers of the modules typically test before upload, then there are automated testing systems with reports for the code once it's uploaded, and users can make bug reports. This is rare (especially on common platforms), but it does happen.
I have encountered it when someone did a module upgrade on a production server and my code no longer worked. It was fixed so quickly that by the time I tracked down the problem there was a new version out for me to point out to the server admin, complete with change logs explaining the bug.
One thing you may want to be careful about on Windows is sharing modules between ActiveState's Perl and Strawberry Perl. Sometimes it works, and you can save disk space by doing it. Sometimes you run across issues and are better off keeping separate module directories for the two installations. It's entirely possible to have AS Perl, Strawberry Perl, and Cygwin (which has its own perl) installed on the same Windows box and not interfering with one another. I've one box here that has two AS Perls, three Strawberry installations of different versions, Cygwin with its perl, and the perl from Microsoft's resource kit, all churning away tests wonderfully. I try to keep all production code on one installation, though, for my own sanity. These issues aren't unique to Windows, actually, but Strawberry Perl and ActiveState Perl are even more different than two perl installations on some other OS are likely to be.
I do most of my Perl (and most of everything computer-related) on Linux, so there are probably several people here who can give you better Windows-specific advice than I can. I know Perl on Windows is fraught with a few corner cases since it's so unlike other platforms (Perl is originally from the Unix world). In general Windows is a nice enough platform for Perl programming and the tools for Perl on Windows keep improving. I think you're probably running into a more general problem that applies to
In reply to Re^3: Win32::GUI::DIBitmap problem
by mr_mischief
in thread Win32::GUI::DIBitmap problem
by djarv
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |