Go to see perl. Scroll down to the History section. Looks at the Incompatible Changes section of the perldelta documents for .0 versions.

• Perl 5.18's incompatible changes
• Perl 5.20's incompatible changes
• Perl 5.22's incompatible changes
• Perl 5.24's incompatible changes
• Perl 5.26's incompatible changes
• Perl 5.28's incompatible changes
• Perl 5.30's incompatible changes
• Perl 5.32's incompatible changes
• Perl 5.34 has no incompatible changes
• Perl 5.36's incompatible changes
• Perl 5.38's incompatible changes
• Perl 5.40's incompatible changes

1. 5.18 introduced more-randomized hashes. This shouldn't break any code, but some code only worked by chance of which order the hash keys landed normally, and will be broken now that they iterate in a different order on every run.
2. 5.24 removed the current directory "." from the @INC include path. This breaks any project that used use MyModule; to mean require "./MyModule.pm";. You can still add the current directory back to @INC manually, but it's much better to organize the module directories and declare them all in perl -I ... or PERLLIB at startup.

BEGIN {
    unshift @INC, "/some/path/Net-Clacks/lib";
    unshift @INC, "/another/path/My-Secret-Module/lib";
};
use Net::Clacks;
use My::Secret::Module;
[download]

At least that's the variant i use when debugging. (Original code checks for the '--debug' flag and only unshifts the uninstalled paths if that is set).

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my weekly webcomics

That works too. I prefer more like

#! /bin/sh
exec perl -I /some/path/Net-Clacks/lib -I /another/path/My-Secret-Modu
+le/lib myapp.pl "$@"
[download]

in a file named debug_myapp.pl, which helps keep my temporary local debugging stuff out of the committed code of the project.

Changes mostly affect exotic features or unsuccessful feature experiments.

I'd say the best strategy is to use perlbrew and install various versions to run your code. Check the logs for errors and warnings.

And try establishing automated tests to assure that your application "works" as intended.

You can either gradually increment the version, or just do a binary version search till it breaks.

My intuition tells me that you'll rather have problems with CPAN modules in your dependency chain or third party components of your application. (I once had an application which suffered from a subtle break after MySQL was upgraded)

But that mostly depends on the quality of your code.