5.16+ has much better Unicode support than 5.10.1, including the "unicode_strings" feature (where all strings are treated as Unicode except in the scope of use bytes or use locale), and the fc function which is useful for case-insensitive string comparisons.

Perl 5.16 has the __SUB__ keyword which acts as a coderef pointing to the current sub. This is useful for writing anonymous recursive functions.

5.14+ supports the package NAME BLOCK syntax, which is cute, but isn't going to change your world.

use v5.12 (or above) automatically enables use strict, reducing some typing.

The yada-yada operator, introduced in Perl 5.12 is handy during development.

There are beginning to be a few nice CPAN modules like Switch::Plain, Fun and Try that use the pluggable keyword API introduced in Perl 5.12/5.14.

Whether these are compelling enough reasons to upgrade will depend a lot on how you use Perl, and what you use it for. I'd certainly suggest having a copy of Perl 5.18 on a development machine to make sure that the code you write runs on it; whether you deploy it for production use is a different matter though.

use v5.12;
versus
use strict;
is not much reduced typing ;-)
(I know it gives more than just strict)

use v5.12; is less typing than use v5.10; use strict; though.

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

At some point older versions will not be supported and have unpatched security vulnerabilities, module updates won't run on older versions of Perl etc.

You should take the opportunity to work out some form of company wide regular upgrade process and to make it as painless as possible. I'm not sure about the benefits of being right on the leading edge, but you shouldn't be too far behind it.

Update: Some people have pointed out that releases are customised and may be difficult to upgrade. There is an argument for leaving the system Perl unaffected and having an independent site Perl, which is hopefully kept up to date.

I agreee that one should not fall too far behind... (tell RedHat)

Company wide upgrade process is in place, that is (concerning this subject): follow RedHat on Linux..

We use satellite server for maintaining OS and other packages. We are a managed hosting company, and keeping the servers updated is natural.

We use perl to write integration code between CMDB and other stuff, on our own infrastructure servers - and here we have the possibility to install our own tools if we need

I know that older versions are not supported by the community (and that the support from RedHat may vary;-) )

My problem is that I lack the arguments, when there are no significant differences between 5.10.1 and 5.18.0. Yes, I know about the security issues, but that goes for all RedHat stock stuff, and as long as we don't expose our services to the public, I think that this argument will only hold half-way through...

thanks for your answer

At some point older versions will not be supported and have unpatched security vulnerabilities

I don't think this is valid argument for RHEL. They maintain and fix perl by their selves AFAIK.

module updates won't run on older versions of Perl

I didn't see much modules, which won't work on perl 5.10 and even 5.8 (but I didn't check some huge frameworks)

RedHat shipped a badly crippled version of perl a few years ago and took a long time (almost two years, IIRC) to fix the situation after being notified.

Forget the upgrade argument, install your own version of perl *just* to isolate your app from vendor choices that may conflict with your own choices. There are some high level arguments on why to leave the vendor install alone on the perlbrew homepage.

For me, this is the primary argument. The vendor's installation is the vendor's. They will not consult you to see if your application will run under a future (or past) version that they want to move to, nor will they rush an upgrade just because your application 'needs' some feature. You are able to test, package, and deploy your application based on your requirements, instead of the current implementation selected by your OS vendor.*

* Yes, this is a broad brush, and there are some instances where using the OS vendor's version of perl is the RightThing, but that is a tradeoff and business / marketing decision, IMO. Just my $0.02.

--MidLifeXis

I think it's valid argument only if your applications are really huge or they're bloatware without testsuite, full of legacy code with 100+ CPAN dependencies and full of technical debt. And you're totally unsure why it would/wouldn't work on certain version of Perl.

Otherwise it will be pretty easy to test it with several versions of Perl, on dev machine, to make sure the code matches Perl specification, and that you are not using some crazy CPAN modules. Any incompatibility will be a good reason to investigate the reason to make sure your code actually does not contain bugs. Easier deploy to RHEL servers is a bonus

Until your OS patch changes the OS's version of perl (or a library) under the hood, breaking the assumptions made by your application. This happens in large enough organizations where 'the canonical OS platform is X.Y.Z, and all machines must be upgraded to X.Y.Z by this and such date' (yes, it does happen :-/ ). Using your own perl gives one fewer moving part not under your control.

If you are releasing on CPAN, then yes - test far and wide. There are times for both approaches.

--MidLifeXis

IMO

If you have to ask :) it isn't worth it :)

Don't worry about new syntax ... not that important, but bug fixes, esp regarding threads are

The other thing is increasingly improved unicode support

This brings you up to perl-5.14.4, or perl-5.16.3

If you're thinking you need some of the fancy new regex features, you don't, all you need is marpa scanless

Re: perldeltas - every perl*delta in one file (pod.lst) ( perldeltas.html#p5144-Security     perldeltas.html#p5163-Security )

I am not sure why in details, but we upgraded some of our servers to Perl 5.16 because it seems to have much better threads.

we upgraded some of our servers to Perl 5.16 because it seems to have much better threads.

Any pointers to the evidence?

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

As I said, I do not really know the details. This is not my main work, but an application for which I only work occasionally. It was previously working on 5.8, if I remember correctly (or perhaps 5.10, but I think it was 5.8), and they decided to upgrade because they wanted to use threads in a new framework developped internaly, and, apparently, it does make a difference. I do not know the details personally, but I would tend to trust the person who proposed that upgrade decision, because I know it is someone who usually knows fairly well what he is doing.

But the point is that the improvement was compared to Perl 5.8, not a more recent version.

In most cases, rolling your own Perl does not require an inordinate amount of work. I refer to you to Perlbrew and cpanminus, both of which can be potentially life-changing.

The benefits of running your own Perl go beyond the new language features (which are significant between 5.10 and 5.18; see perldelta for more information). By running your own Perl, you gain complete control over what you upgrade, and when you upgrade. OS Perl releases are often for the benefit of the OS itself: to support scripts used by the particular Linux/UNIX distribution you run, so those releases tend to lag pretty far behind. In this case, five and a half years! The releases are often patched as well, either to backport bug fixes, or for other reasons. Hence, you are not running vanilla Perl.

For these reasons, you will often have trouble installing CPAN modules, and are often faced with the dilemma of whether to use the (older) RPM provided by your Linux distribution, if anyone bothered to package it at all, or abandoning it entirely if it won't install via CPAN due to incompatible dependencies or Perl version.

Running your own Perl will fix these issues, but note that any Perl modules that depend on C/C++ libraries may still cause problems if the RedHat versions lag too far behind. Staying with the OS Perl and OS-packaged mods usually avoids this issue by keeping all the versions in sync even if they're old, or not providing packages for newer modules.

Nothing's perfect, but once you get past the fear of the unknown and acclimate to the perlbrew process, many headaches go away.

That being said, upgrading the programming language (or its modules) that underlies a large programming project is not something to be done on a whim, as interfaces can change, subtle changes can cause bugs (such as the hash order randomization change), and other unexpected problems can occur. That is not to say that upgrading isn't worth it, but you would be well-advised to have a fallback plan, and an excellent suite of unit tests and manual test plan to quickly find any regressions.

For these reasons, you will often have trouble installing CPAN modules

You're overstating the case. Granted, I'm a sample size of one, but, although my primary job description is "Perl programmer", I'm also the local devop[1], so I maintain several boxen running a mix of distros[2], some of which are rather ancient[3]. With the exception of Perl 5.8.x vs. 5.10, I have never encountered an issue with a CPAN module failing to install due to the system perl being too old. OP said he's currently on 5.10.1, so my experience suggests that this should not be an issue for him.

[1] ...and used to be a full-time sysadmin, once upon a time.

[2] The ones I install tend to run Debian and legacy systems are mostly Red Hat, but just about anything can pop up on occasion - SUSE, Mandriva, you name it.

[3] The current oldest is a Fedora Core 5 server, which we finally managed to start moving things off of just last week.

I am frankly quite intrigued why you say, “overstating the case,” because I certainly have encountered incompatibility issues on a great many upgrades.   And, given that RedHat’s most-essential software tools run on Perl, that does become a serious concern.   I am not challenging your POV, but it does surprise me to hear this.

summary

• security fixes
• indepence of /usr/bin/perl
• improved UNICODE support
• improved thread support
• misc. "minor" syntactical sugar (package Foo VER, __SUB__,

My €.1 about relying on stock /usr/bin/perl vs. latest and greatest:
It is true that vendor may choose to upgrade their perl in a way that is incompatible, and that this may hurt us. But that will be true for anything installed on a box: libc, libssl, openssh, bash. The reason for incompatiblity may as well be due to some community/-ies changing policy/-ies (like openssh vs. bash and the handling of .bash*). And the incompatibility problem would certainly have hit us if we had choosen latest and greatest, as 5.18.0 did move the given/when and ~~ into experimental mode (and thus removing my best arguments...).

The only feasible way to handle this problem, is (at least in our case), automated testing of our perl modules/scripts and all our other stuff, to ensure it works in the next new environment, whether it is new due to satellite server upgrades and/or a new version of latest and greatest.