Re: What is a really old version of Perl?

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.)

Comment on Re: What is a really old version of Perl?

Replies are listed 'Best First'.
Re^2: What is a really old version of Perl? by Tux (Canon) on Jun 27, 2012 at 12:36 UTC
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). Enjoy, Have FUN! H.Merijn	[reply]

Replies are listed 'Best First'.

Re^2: What is a really old version of Perl?
by Tux (Canon) on Jun 27, 2012 at 12:36 UTC

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).

Enjoy, Have FUN! H.Merijn

[reply]