What is a really old version of Perl?

[Argel]

I've noticed that many Monk's tend to overlook that Perl is used by system and network administrators, systems engineers, biologists, and other less traditional developers. In that light, cavac's recent question in Re: Perl installation broken seems like a good opportunity to raise some awareness of the world we (system engineer here, and I work with our networking teams a lot) live in.

The question was:

Are you really running a very old version of perl (5.8.8 in this case)?

And if I was asked that question, my answer would be that Red Hat Enterprise Linux (RHEL) 5.x ships with exactly that version! And support for RHEL 5 ends on March 31st, 2017! And after that, there are three years of extended support, so all support actually ends on March 31st, 2020!

Additionally, RHEL 5 is the RHEL version to deploy on these days. That's because RHEL 4 entered it's extended period of support earlier this year, so it is being phased out. And while moving to RHEL 6 is picking up steam, it's still a bit too new -- e.g. a lot of vendor apps still do not support it. And it should go without saying that in the corporate world, on the server side, RHEL is king, along with distros based off it of it like CentOS (e.g. hardware vendors making probes and appliances tend to use it to save money).

And so, the next time someone asks a question about an older version of Perl, please keep in mind that that really old version might be what their current, still supported OS ships with.

And before someone suggests compiling a newer version, for better or worse, the version RHEL ships with is covered by Red Hat's indemnification clause, which makes it considerably more difficult to justify compiling a newer version to management and the legal department. [ Update: Of course, it makes it easier to get approval for things that RHEL does ship with. ]

Source: RHEL Product Life Cycle

As a side note, if you do compile a newer version, my recommendation is to install it to a new location. It's poor system administration practice to modify the version the OS ships with because new patches could break it, the OS may have tools and scripts that rely on that version (e.g. Solaris 10 does), and it's possible a vendor out there expects the version that ships with the OS to be there.

[BrowserUk]

I think the problem here is pretty obvious:

1. 5.8.0 Jul/2002 -- 5.8.9 Dec/2008 :: 6 years.
2. 5.10.0 Dec/2007 -- 5.10.1 Aug/2009 :: 2 years.
3. 5.12.0 Apr/2010 -- 5.12.4 Jun/2011 :: 1 year.
4. 5.14.0 May/2011 -- 5.14.2 Sep/2011 :: 5 months.
5. 5.16.0 May/2012 -- last version in July or August?

Taking old versions out of support based upon the number of new major versions since its release, when the lifespan of each new release is getting geometrically shorter, is a crock.

[Anonymous Monk]

... getting geometrically shorter, is a crock.

Would you care to elaborate?

I don't remember seeing an official written support policy anywhere before 5.12.3 in 2011-Jan

Or for that matter a release schedule.

I like the new commitment from the community and I think two major versions, and 3 years of security fixes is enough official support -- with any backporting done by those who need it.

5.18.0 is projected for 2013-05-18, so the release schedule is fairly stable -- looks like a good idea to me and definitely not a crock.

For those who want to know see perlpolicy#MAINTENANCE AND SUPPORT

This document codifies the support and maintenance commitments that the Perl community should expect from Perl's developers:

• We "officially" support the two most recent stable release series. 5.12.x and earlier are now out of support. As of the release of 5.18.0, we will "officially" end support for Perl 5.14.x, other than providing security updates as described below.
• To the best of our ability, we will attempt to fix critical issues in the two most recent stable 5.x release series. Fixes for the current release series take precedence over fixes for the previous release series.
• To the best of our ability, we will provide "critical" security patches / releases for any major version of Perl whose 5.x.0 release was within the past three years. We can only commit to providing these for the most recent .y release in any 5.x.y series.
• We will not provide security updates or bug fixes for development releases of Perl.
• We encourage vendors to ship the most recent supported release of Perl at the time of their code freeze.
• As a vendor, you may have a requirement to backport security fixes beyond our 3 year support commitment. We can provide limited support and advice to you as you do so and, where possible will try to apply those patches to the relevant -maint branches in git, though we may or may not choose to make numbered releases or "official" patches available. Contact us at <[e-mail]> to begin that process.

See also http://search.cpan.org/dist/perl-5.17.1/Porting/release_schedule.pod, perlhist

[BrowserUk]

Assuming this was intended as a reply to my post rather than bulk88's.

With 5 months between major versions, that equates to a whole 10 (TEN) months before all a vendors efforts to ensure the distributed version of perl works with all the distributed packages and tools it supplies written in perl are obsolete. It isn't long enough.

It is no wonder that vendors (redhat et al) are choosing to stick with old versions. With Perl's major version changing twice (or 3 times) between vendors major releases, by the time they've frozen their distribution and taken it through their testing processes to a release, the Perl they included is not just out-of-date, it is out-of-official-support.

With the recent rates of turnover, there is never a period of stability long enough for them to get from code-freeze to release. And if they've got to stick with an out-of-support version, why wouldn't they stick with the one they know.

Or more likely, drop their dependency upon the unstable moving target that is Perl, throw in an old version as a token gesture, and move over to using Python.

[moritz]

Well yes, perl 5.8.8 is a really, really old version of Perl. It was released in 2006 (6 years ago). The next maintenance release of the 5.8 series, 5.8.9, was released in 2008. It is now 4 (in words: four) major releases behind the state of the art.

The fact that some linux distribution chooses to ship such an outdated version doesn't change the fact that it's outdated.

For the Perl community, the solution cannot be to support old Perl versions forever, but to encourage timely upgrades.

Continually nagging about outlandishly outdated versions of Perl seems to be a good way to make people aware of that. Maybe the customers then can give feedback to RedHat (and not to perlmonks) that their Perl version is outdated, and they should change to a newer Perl version for their next release, please? Hey, even Debian Wheezy (which will be frozen soon, and released a while later) comes with perl 5.14.

And so, the next time someone asks a question about an older version of Perl, please keep in mind that that really old version might be what their current, still supported OS ships with.

The problem with that is that people expect to rest comfortably on their 6 year old Perl version, and still expect to use new stuff with it. Or to phrase it differently:

And so, the next time you ask about an outdated version of Perl, be aware that you are several years behind the times, and ask yourself if you can't get support from your OS vendor, who brought you into your current misery.

[bitingduck]

It's not just Linux distros. Mac OS X (not sure if it's base OS X or the developer tools-- I haven't had a machine without dev tools in ages) still ships with old versions of Perl. Snow Leopard has 5.8.9 and 5.10.0. It looks like Lion is up to 5.12.X, and it wouldn't surprise me if it's still got 5.8.9 in there, too, for some legacy functions.

But with a Mac (and probably any other OS that comes with a Perl install) it's highly recommended that you don't touch any of the system installs, and install your own instead. Anything you do to their installs isn't guaranteed not to be overwritten by some future update. On snow leopard I mostly got away with installing into the 5.10.X, but found that it behaved a little wrong with some modules. I've since switched to Perlbrew and it works well.

[DrHyde]

I sympathise. Really, I do. I know what a pain it is testing your applications with new versions of their dependencies, deploying those new versions (and any necessary fixes to your code), all without breaking any live services. And it annoys me when some ignorant loudmouths in the community refuse to recognise the constraints that some monks have to work under.

But you can't expect people to support 5.8.8 any more. It's six years old now. By 2017 it'll be over a decade old and by 2020 it'll be legal to marry in some backward countries. You can't expect volunteers to maintain something for free for that long. If Red Hat are going to sell support contracts that are that long, then supporting the software is their problem.

I understand that DEC used to sell even longer support contracts for VMS. It got to be so burdensome that they were offering quite large sums of money to their customers to migrate to more recent releases and terminate the existing contracts.

[Argel]

You read way too much into my post. My point was that it's not so unexpected to see questions from Monks still using Perl 5.8.8 (and by extension, pestering someone about it could be considered poor form).

Regarding VMS, and going way off on a tangent, Hughes used it for the management software for their commercial satellite gear (PESVOC: Personal Earth Station Virtual Operator Console). We had maybe 8-10 Vaxes and I think four DEC Alpha's running VMS here several years back. PESVOC was an X-Windows app, so the networking teams accessed them via a Sun server and either Sun Rays (hardware thin clients) or Citrix XenApp for UNIX (aka MetaFrame for UNIX; software thin client). I assume the various buyouts forced Hughes to port the app to something a bit more modern (or rewrite it or replace it). As a side note, IIRC, Hughes wanted to (and did?) sell off the commercial part of the satellite business.

Anyway, most companies have moved away from satellite to Frame-Relay, MPLS, ATM, DSL, etc.

[tobyink]

"By 2017 it'll be over a decade old and by 2020 it'll be legal to marry in some backward countries."

Backwards countries like Canada and (parts of) the United States? Granted you need a court order to marry at 14 in these places; but what marriage could be more legal than a court-ordered one?!

I believe in Yemen you could marry Perl 5.16 - you just couldn't consummate that marriage. (I'm not entirely sure how you'd go about consummating marriage to a Perl release anyway. You'd probably need to install Sex.)

[patcat88]

Inseminate the makefile and build an offspring.

[DStaal]

I've argued this a few times myself. Work uses a combination of just-barely-in-support Solaris boxes and RHEL 5. 5.8 is the new version of perl that's supported - if it needs to run on all the boxes I need it to work with 5.6.

Yes, I know it's out of date. Yes, I know we should upgrade. That is not my decision and not under my control - and if I try to sideload a newer version I'd get fired. A better job would be welcomed, but this one isn't worse than most from what I've seen, and it would cost me $10k to move.

Besides, from a system administration viewpoint, staying on these old versions makes sense - and programming is only a small portion of my job.

I don't mind an answer that uses newer perl syntax and features - I can translate back to a two-argument open (or whatever) if I need to. What I do mind is the attitude that I shouldn't be worth talking to because I have this requirement to run under older perls, or that a minor update in a module should be expected to break for me, even if there is no reason for it to. (From the 5.6, there is often a good reason, I'll admit.)

[Tux]

People like you are the reason why I keep trying very very hard to have my CPAN modules support old(er) versions.

I am really very sorry to tell that I had to drop 5.005 support, but I now ran into problems that needed 5.6 or up. Some of my (perl) friends cheered in my decision to drop 5.005, but until I did, the burden to support it was low. Now that I dropped it, a lot of stuff got easier and I somehow regret not dropping it earlier.

I still have over 100 versions of perl available on my USB testing disk, and I notice that it is getting harder by the day to support 5.60 and 5.6.1 as the required toolchain just won't install anymore, so I'm actually stuck with 5.6.2 or newer for a lot of recent development. At least it proves that perl's own development hasn't stalled. Most failures for 5.6.1 and older stem to compilers that are newer than what those perl versions support or library mismatches between when those perls were built and what the system currently offers. Well, there is no easy workaround to that.

In my job I have the relative luxury that I have been able to convince the clients to not use system perl (on HP-UX and AIX) as they do not reliably support 64bitnes and/or Unicode, two major requirements for most perl processes run in customer environment. Now we - as 3rd party - can decide what perl version we install on the client side next to the system perl (which isn't used at all by our applications).

[raybies]

i use old versions of Perl all the time (i.e. RHEL 4/Perl 5.8.5). Occasionally I run into a problem with modules, but for the most part it all still works great. In one case the computer can't be updated, but it's necessary to continue development on it. It's running an old bugzilla system... and I've looked into porting it to a newer machine, but because it's so old, it's looking to be painful.

[Anonymous Monk]

I started learning Perl back when Debian had 5.6 installed as default. This was probably in the Potato days -- 2001 or so.

Usually I sample a few systems I use, and code for the oldest one. Today Debian (stable) has 5.10.1, FreeBSD 5.12.4, and Gentoo was at 5.12.* IIRC. Therefore, I'd consider 5.10 a "safe" version.

Here's the odd thing. I still code as if I was coding for 5.6. I suspect much of my code (except perhaps the things dealing with character encodings) work fine in that version. I just don't have an installation that old to test on.

No, I haven't scoured perldelta for interesting things. I just decided that, being the conservative person I am (tech-wise), I don't actually need the features offered in 5.10. State variables can be done without a special keyword. given/when syntax feels alien to me. Smart-matching, well, it can come in handy, but I never learned to use it. Defined-or is just a shortcut. Yes, I suppose I would use those features the times they greatly enhance the clarity of the code, but the other times, I'll just keep on coding in my old ways.

All this really leaves up to question is CPAN modules. They are free to depend on a version >5.8, and my installed Perl hopefully accommodates that dependency. I haven't been bitten by that sort of thing yet.

[cavac]

From a technical and availability standpoint, there is just no reason to keep using such an old version of perl.

I just tested this today. First what you have to understand is that i'm not using whatever version of perl came with the operating system. I always use a separate installation for my applications (that way, my upgrades/updates don't interfere with the operating system and vice versa).

I logged in to one of my development/test servers where i was running ActivePerl 5.14. The webserver (written in Perl) and all it's background workers where running. I did a parallel install of ActivePerl 5.16. Change the bash script that starts all the scripts to use the new path. Called killall -9 perl, called the startup-script and deleted to ActivePerl 5.14 folder. Total downtime of the service was about 25 seconds. Total work time was about 2 hours (including the 30 minute fire drill that interrupted me in the middle).

Also, i guess, using such an old version of perl such as 5.8.8 means you can't use a lot of newer, bugfixed and enhanced versions of CPAN modules. Isn't that a rather nasty security risk?

What about IPv6 support? If you are running such old software, i guess IPv6 support is sketchy at best. If you are doing any network stuff (especially on the internet), you should think reading RFC 6540: IPv6 Support Required for All IP-Capable Nodes. Basically, if you can't fully support IPv6 (doesn't say you must have an uplink, just be IPv6 capable), you are making a product that is does not fulfill the requirements to label it "Internet-capable".

[DrHyde]

I can't believe that I forgot to mention cpXXXan in my earlier comment. It's what you want to use for installing modules on older perls.

[bulk88]

I would say Perl 5.0 was major (objects). Somewhere in the 5.8 (unicode) series was major, and 5.10 was less major (ithreads). I personally use 5.10 as my "old" Perl to test with, and code to 5.10 or 5.8 or even accidentally older. 5.6 and some of the 5.8s I consider a totally different generation than todays. In the 5.8 series, major changes were done in the minor version numbers, unlike today.

[tobyink]

Personally I'd say if you're using anything older than 5.10.1, then you're a lost cause.

Some major new features were added in 5.10, including state, given/when, smart match and the defined-or operator. (Not to forget say, which although not major, is nice.) There were also important but less visible internal changes, such as to the regular expression engine. And there were some pretty big changes in the supposedly minor upgrade 5.10.1, including improvements to smart match, a Unicode upgrade, and autodie and parent becoming part of core.

Releases since 5.10 have had new features too, but these seem less compelling. Although I currently use 5.16, I have so far eschewed relying on post-5.10 features in publicly distributed code, preferring to keep compatibility with 5.10.

With regard to RHEL, it is well-known for shipping pretty ancient releases of software. Luckily, App::perlbrew will happily run on Perl 5.8.

PS: If the legal department object to installing a newer version of Perl via perlbrew, then it seems they would be unlikely to be thrilled about you downloading and executing random code from the monastery at all.

[tye]

Personally I'd say if you're using anything older than 5.10.1, then you're a lost cause.

Congratulations, you are officially a lost cause!

You just used a release of Perl 5.008 to post that proclamation.

I personally don't know how you guys keep posting nodes without state variables. Sheesh!

[tobyink]

My point is not that nobody should run 5.8, but rather than nobody should run 5.8 and expect to be able to download recently written code and have it "just work".

Using a legacy version of Perl to run legacy code (and I understand it, there's a picture of the Perlmonks code if you look up "legacy code" in the dictionary) is clearly fine.

Perl 5.8 first came into this world in 2002; the same year as Windows XP. The latest releases of Internet Explorer don't run on Windows XP. If one of the largest commercial software developers on the planet will not support products 10 years old that have had multiple stable releases since, then why should unpaid open source developers?

[Anonymous Monk]

I've noticed that many Monk's tend to overlook that Perl is used by system and network administrators, systems engineers, biologists, and other less traditional developers.... And so, the next time someone asks a question about an older version of Perl, please keep in mind ....

Must be confirmation (or some such) bias :)

What is a really old version of perl?

One which isn't supported by perl5-porters, which ATM means anything below 5.14

So RHEL suports some antique version of perl -- great for them, they get MONEY for that.

If you want to give me MONEY I'll keep this in mind also

But you're not going to give me MONEY are you?

If you want consideration be nice and send money

[Argel]

Education and awareness were the main goals of my post. That was predicated on the notion that The Monastery's doors are open to all those seeking Perl enlightenment. A hat tip to tye, BrowserUK, raybies, and DStaal for displaying that aspect of The Monastery. To the rest, many of you seem to have missed the intent of my post. Interesting discussion regardless.