I use my laptop as test environment. When all (upgrades) pass on production/utility software, I upgrade my workstation. If that shows no problems after a few weeks, I start upgrading other production servers.

So I installed 5.18.0 on my laptop as default perl, and then tried to install all CPAN modules I ever used in 5.16.x

There are just a few things that stand out as a reason for FAILure:

Test files that use for $foo qw( … ) { which is now deprecated. The module autor should rewrite that to for $foo (qw( … )) {. I filed RT tickets for all I encountered. Lets hope the authors will fix their code.

POD failures. As the POD checker is now way stricter than the old version was, it shows more real trouble. And it should! The problem is that many authors ship the pod tests too, so the test suite will fail if Test::Pod and friends are installed, and thus cpan won't install those modules. That means manual work ignoring the pod errors (and when obvious file RT tickets). Authors: unless you keep in sync with reality and release often, please do not include pod tests in you distribution.

Loads of warnings when a module uses given/when as those are now marked experimental. I can ignore the warnings when testing, but will they fill up my logs when run in production code? When the module also uses Test::NoWarnings, one cannot install. A module like MooseX::App now won't install, and it causes many other modules that have this as a prerequisite to fail too.

XS authors that never updated ppport.h from Devel::PPPort. Easy to fix.

Modules that use Module::Install but ship ancient or incomplete versions of it in inc. The easiest solution for me was to just recursively remove inc/ and all problems vanish. I have no tuits to RT all of them.

Several modules fail because they declare optional deps that are actually hard deps, like using JSON::XS, Lexical::Sub or Data::Alias - which won't build under 5.18.0

Test failures, or maybe even code failures, due to hash randomization. Unless I am absolutely sure that the test is wrong, I cannot install these modules.

Some failures have been reported to the authors but the available fix has not (yet) been applied (like in Template::ToolkitRT#84778) or not yet released (Tk and SQL::Statement). When their repository is open, they build fine from the repo and I am confident the next release will build fine.

The message is: perl-5.18.0 is awesome, but please please test the module you require before starting the installation on machines other than a test environment.

A further annoyance with the experimental features is that "use 5.018;" only enables some of them (e.g. 'smartmatch' is enabled while 'lexical_subs' is not). In addition, it would be useful if the error or warning messages actually stated what the related feature was (or vice versa).

Here's some examples.

This produces warnings about given and when (you need to know that the feature is smartmatch) and an error about "my" subs (you need to know that the feature is lexical_subs):

Enabling lexical_subs in the first example, the code runs but with lots of warnings. Note the warnings inconsistency of given/when mentioning the code but not the feature and lexical_subs mentioning the feature but not the code (which, in itself, is inconsistent with the lexical_subs error mentioning the code but not the feature):

The behavior of given/when/~~ are likely to change in perl 5.20.0: either smart
match will be removed or stripped down. In light of this, users of these
features should be warned.

So it seems the annoyance is intended, to motivate us to phase out the usage of those features in our scripts.
Still, I think the point would have come across more clearly if the warning would read "Smartmatch is deprecated" instead of "experimental"...