Perl 5.8 has been unsupported for a while now, so if you find a bug in Perl 5 itself, you're going to have to fix it yourself. (Canonical probably isn't going to support it for you.)

If you find a bug in one of your CPAN modules, you may or may not get support from the author for Perl 5.8. That depends on the author. (I don't support 5.8. Canonical probably isn't going to support it for you.)

If you need working Unicode, 5.12 is really the earliest version of Perl 5 that has anything close to complete support. 5.14 is your best option.

(Perl 5.12 is a bit faster than 5.10 and uses a little less memory, and 5.14 continues that trend.)

Unicode support is very important to us since we process international text.

I thought that Unicode was added in Perl 5.8. I'm curious as to how much better the Unicode support is in Perl 5.12 vs. Perl 5.10 vs. Perl 5.8.

Thanks

Only as of 5.14 are most of the builtin operations fully aware of Unicode; too many of them default to assuming the semantics of whatever the local character set is. unicode mentions this as "The Unicode Bug". Perl 5.12 fixed some of that, but only as of Perl 5.14 can you use use feature 'unicode_strings'; to get Perl to do the right thing.

I haven't encountered huge problems in my work, but most of what I do uses nothing more exotic than Latin-1 and UTF-8, so I've been fortunate. Then again, everything I care about runs on Perl 5.14.1 (and soon Perl 5.14.2).

---

Improve your skills with Modern Perl: the free book.

As I understand it, the Perl used by the system and the Perl used by other code need not be the same and it can be a very bad idea to change the system Perl. Now, I'm a Losedows user, so take this with more than a pinch of salt until it's confirmed by someone who knows more.

It's certainly possible, on any operating system that has the disc space, to have more than one version of Perl. My approach, therefore, would be along the lines of identifying a real operational need for a single application that needs a later version. If it ain't broke, don't fix it. If you have the operational need, then try to persuade them to allow the parallel installation of a later version to be used for that application only. Once you have demonstrated that the two can coexist and that the additional functionality is useful, you can start playing a recording of "wouldn't it be nice to standardise on a single version".

But I repeat for emphasis two points: don't change the system Perl and don't fix something that's working.

Regards,

John Davies

Update based on chromatic's reply: you can point out that, as 5.8 is deprecated, you will have to upgrade if you upgrade the OS to a later version, so it would be helpful to start finding out what problems exist in good time.

What arguments could be used to justify an upgrade like this?

Let me ask you, is upgrading to 5.10 (or 5.12 or 5.14) going to make your company more money (now and in the near future)? Don't forget to deduct the cost of the upgrade itself from any increase in revenue (or to add it to whatever savings an upgrade is giving you). If you cannot make a business case for it - don't upgrade. Or at least, don't do it now. Don't forget that your customers don't give a flying fuck whether your server runs perl 5.8, perl 5.10, perl 5.14, perl 6, ruby, python or something else. They just want whatever service or produce you're providing.

Sorry, but another vote for leaving it alone. If you're stuck on particular bugs, or if modules you use regularly have been upgraded and only work on later versions of Perl, that could give you the basis of your case for upgrading. But why 5.10??? The fact that you're talking about only getting the features in 5.10 suggests it's more of a "latest and greatest" kind of thing than any real business need. Perl 5.10.1 fixed a bunch of bugs in 5.10, and there are two major releases after that, with 5.16 not too terribly far away; so upgrading to 5.10 is just pointless.

Still, if you just want to install a more recent perl, perhaps pointing out to your bosses that you're three major releases behind, you could also replicate CPAN on a local machine, and install current modules from there.

But if all you want is say and given/when, you can replicate something quite close to those quite easily.

The project is still being developed with me as the primary coder. My sense was that a new version of Perl would make me more productive and allow for a cleaner code base. I use modules by switch and say but there's no way to replicate other features such as '//='

Of course, it's hard that quantify benefits like that. It's true that there's a one time cost to upgrading and that it would be possible to continue development with 5.8. On the other hand, just because a technology works doesn't mean it's optimal to continue using it. For example, Perl 4 could also be used for a project but Perl 5 clearly results in better productivity and higher quality code.

If Unicode is a vital part of your project, specifying just "5.8" is not enough. I really cannot think of any application running code to deal with Unicode reliable on anything older than 5.8.4. In the (way too) long development life-cycle of 5.8.x Unicode support has hugely improved, so 5.8.8 will do MUCH better than 5.8.5. This trend set on in subsequent releases, and if Unicode is core business, moving towards 5.14.2 is a very healthy move. The jump is big though, and you will have to test everything very carefully.

Using modules like Switch is a VERY bad idea in 5.8, especially when you plan to use defined-or in 5.10 and on. They do not combine and scripts will crash in unexpected ways. I always used perl 5.8.x with defined-or (//=) built-in ( yes, there is a patch available to make 5.8.x have // natively), so I hit that problem in early stages and decided to never use Switch ever again.

Then came given/when, but it was based on smart-match, which has its own snakepit of unpredictable issues.

Summarizing: a move from earlier 5.8 to later 5.8 is warranted by 64bit issues and a little bit of Unicode. A move to 5.10 is warranted by the defined-or being available by default and much better CPAN support: authors are dropping 5.6 by the masses and 5.8 will be dropped rather sooner than later. A move towards 5.12 or 5.14 is good if your Unicode processes are core business.


Enjoy, Have FUN! H.Merijn

I would really like to get the production machine moved to 5.10

There are arguments for and against upgrading, but upgrading to software that's been end-of-lifed? I think that's a waste of time.

Thanks for pointing that out ikegami, I wasn't aware that Perl 5.10 had been end-of-lifed.

The reason I was thinking of Perl 5.10 was because that's the version that the latest Ubuntu LTS (10.4/Lucid) supports. Upgrading to a non-LTS version of Ubuntu means you only get support for a year and then have to upgrade again.

Installing a local version of Perl separate from the Ubuntu repos is possible but not ideal.

Upgrading to a non-LTS version of Ubuntu means you only get support for a year and then have to upgrade again.

It just goes to show that using the distro's Perl places the choice of whether to upgrade or not out of your control. Sometimes, it's ok to be at the mercy of another company. Sometimes it's not. I can't answer that for you, but asking the question you are asking seems to indicate it's not.

(Previous paragraph rewritten based on better understanding of quoted line.)

Installing a local version of Perl separate from the Ubuntu repos is possible but not ideal.

I think it's *much* better than the alternative. Three major advantages:

• You don't have to run the same OS and OS version on every machine.
• You can upgrade or not upgrade Perl independently of other upgrades to the machine.
• You can test your application with a new installation of Perl while still having the old version installed. This allows you to make sure the machine is setup correctly risk-free, and it allows switching to the new Perl without any downtime.

8.04 has server-class support until 2013.

Even so, 5.10 is at its end of life too, so that's just delaying the inevitable.

---

Improve your skills with Modern Perl: the free book.

that's just delaying the inevitable

But still, it's better than doing nothing. The next step would be to update the staging machine to the next LTS version, that hopefully has a newer perl. As a nice side effect, dlarochelle gets a chance to plan for continuous updates, and to test that plan.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

I'll join in with the dreaded phrase 'technical debt'; the longer you put this off, the greater the risk. One of the rules of business is that you prefer to minimize risk. So get a new production server, install the latest OS on it (which will include the new Perl), update everyting, and see how it behaves.

At some point, like tearing off a band-aid, you have to get started. You're already living on borrowed time with your existing server. There's a greater risk in doing nothing, rather than getting started.

Step into your management’s shoes and attempt to construct a business cost/benefit/risk analysis.   This is a production system with over two hundred CPAN modules ... and exactly where is the overwhelming business justification to change anything?

I’m not saying that such a justification does not exist.

... and exactly where is the overwhelming business justification to change anything?

In my business, where I am the technical manager, it's very simple. We don't run unsupported versions of Perl. While we may never run into bugs in Perl that could block our business, the fact that we're never getting those bugs fixed in unsupported versions is a bigger risk than that of upgrading frequently.

A blocker bug means we lose real dollars. Testing an upgrade means launching an automated process and, almost always, getting the green light to proceed.

Certainly upgrading regularly has an upgrade tax, but in the case of Perl it's reasonably easy to test upgrades and deploy upgrades, and that tax is much, much less with a good process for upgrading regularly. Perl 5's predictable release and upgrade schedule, as well as the entire CPAN infrastructure, is immensely helpful.

---

Improve your skills with Modern Perl: the free book.

/me nods...

And in my business, ditto, so do we.   After carefully weighing, for example, the potential impact to any system-management tools being used by a distro vendor. We often compile Perl from source, just the way we like it, and put it into /usr/local/bin.   We also deploy CPAN libraries into a /usr/local subdirectory and make sure that we are referencing it at the exclusion of any system-provided modules.   You have to maintain absolute jurisdiction over the entire environment that affects whatever you deploy, and every part of it has to be precisely reproducible in the test cases.   So, there is always a business necessity to be weighed, and a deployment and testing and maintenance plan to be drawn-up and so on.   It can be “quite the bit o’ busy-work,” actually...

It’s really rather annoying, for lack of a better word, that the language-system versions used by many distros are routinely so old.   But they all build up quite an assortment of system management tools which are dependent on that stuff, and I know they don’t have too much of an alternative either.

However, an upgrade at some point is inevitable. The next Ubuntu server won't come with 5.8

A separate install of a latest perl for one application allows you to do get things done at your own pace rather than when you upgrade the server. You can test your other applications one a time and be ready for the Ubuntu upgrade when it occurs.

The question is are you able to do it and prove it to your boss that there is low risk? Do you have good automated tests? At least enough do demonstrate that 'it mostly likely will work, until users do something screwy'?

My argument would be that as you expand the code you are going to want to use some new feature or bug fix and then that is going to cascade into dependency hell trying to get it supported.

200 CPAN modules shouldn't be an issue unless you don't archive them and have a list of supported versions. I had an app that by the end of 3 days required me finding and installing 125 modules. That led me to come up with an XML file that would describe what modules I wanted, what the dependencies where and other things I needed to consider. I then took a few days to create a script that would read it, build, test, and install modules. Only took about 2 weeks of active use to work out all the bugs in it, but I use it all the time now with no issues (unless a module has a screwy install).

I believe it would be better in Ubuntu to setup a new Perl instead of one of 200 CPAN modules borking up the system. While the CPAN shell is nice about resolving dependencies, you don't really realize how big some of those trees are (XML::Compare needs at least 18 modules). Alternative is to make a new location for CPAN modules in your app and make sure your privileges are read only on your system perl.

Instead of a version that is in the repositories, you probably want a home built copy of perl in some place like /usr/local/bin . This way your scripts can call it for the latest in Unicode/RegEx/Feature support and the vendor's perl scripts can run off the vendor's version.

Building Perl on Unix/Linux is easy, and since you won't be using the system's perl for custom coding, you won't need to update CPAN modules against the 5.8 lib/ directories. In fact keeping your modules up to date against a current version of perl will probably be (only slightly) less effort.

Enormously good reason to upgrade: Exceptions are much less broken.

Quick explanation: During stack unwinding when an exception was thrown, your exception might be clobbered from $@ (A simple eval somewhere in code called from DESTROY of an object can do the trick). That no longer happens with 5.14. This kind of error is among the worst to debug I've seen.

I would like to add an argument not to upgrade too fast. I am testing a 5.14 installation and found some not working modules:

UNIVERSAL->import is deprecated and will be removed in a future perl a
+t C:/Perl.514/site/lib/POE/Component/Client/TCPMulti.pm line 30
BEGIN failed--compilation aborted at C:/Perl.514/site/lib/POE/Componen
+t/Client/TCPMulti.pm line 30.
[download]

So do a complete testing and allow You some time to checkout all your scripts and apps as this might save you a lot of work later. It was already said above, never change a running system without need. Unsupported software is a big need - as chromatic explained - but update carefully