The Perl 5 porters officially ended support for Perl 5.8 on November 5, 2008. Fortunately, Enterprise Support exists to help your legacy Perl 5 installations cope. Distributions such as Red Hat Enterprise Linux and its offshoot CentOS will continue supporting old versions of Perl 5 for up to ten years since their release (the release of the distribution, not the release of the version of Perl 5 they distribute).
For example, the most recent CentOS release, CentOS 5.6, includes Perl 5.8.8. (CentOS 5.6 came out just over a month ago. Perl 5.8.8 is seven stable releases out of date.)
In seven years, when CentOS 5.6RHEL 5 reaches the end of its supported life span, Perl 5.8.8 will have been unsupported by Perl 5 Porters for nine and a half years, and will be almost thirty five stable Perl 5 releases out of date.
But it's supported and it's enterprise, so the CPAN authors of 2018 must be sensitive to the needs of their users, and so the earliest you can rely on Perl 5.10 features such as
If Perl 5.16 gets a meta-object protocol and support for a stripped-down version of Moose as its default object system, CPAN authors can start using it in 2019.
If that doesn't make you want to fire up your favorite text editor and start making plans for all of the wonderful things you will eventually be able to do in the far future, consider also this. If the oldest supported version of Perl 5 is 5.8.8 (even if the people who wrote it and maintain it and support it have disclaimed any interest or desire or intent to support it), then every subsequent version of Perl 5 is a supported version of Perl 5. With Perl 5 on a well-tuned yearly release schedule, you can expect a new major release once a year and three or four point releases in that major release family every year. That is to say, Perl 5.12.0, 5.12.1, 5.12.2, and 5.12.3 are supported. Perl 5.16.0 through Perl 5.16.3 will be supported.
Because you as a CPAN author can't leave all of the people paying good money to CentOS to support Perl 5.8.8 for the next seven years out in the cold, you have a lot of free time not using new features or removing workarounds for Perl 5 bugs, and you can use that time to test your code on an ever-increasing number of supported releases of Perl 5 in the intervening years.
Fortunately, we have great tools such as App::perlbrew which can install multiple parallel versions of Perl 5 without conflicting with the system Perl 5 installation, so that you can install Perl 5.8.9, Perl 5.10.0, Perl 5.10.1, Perl 5.12.0, Perl 5.12.1, Perl 5.12.2, Perl 5.12.3, and (soon) Perl 5.14.0 on your CentOS 5.6 or RHEL 5.x system to test that your code will continue to run on every supported version of Perl 5.
(I know, I fib just a little bit. There's no supported RPM of perlbrew available for CentOS or RHEL. What can I say? I'm an idealist. At least it's only seven short years before the Perl 5 world can rely on Enterprise Distribution users being able to use tools such as perlbrew.)
This is still a big job, so the Perl 5 world needs even more people to donate their time and skills and effort to making sure that code written and donated by other volunteers continues to meet the needs of people paying third parties for the privilege of installing RPMs that are guaranteed never to change for seven to ten years.
Fortunately, this is an easy process to automate with Perl 5. I have some proof of concept code which will test a distribution against all supported versions of Perl 5. Sure, it takes quite a while for each test run, but computers will be faster in seven to ten years when I can release it. (I'd release it now, but I was lazy and used named captures, a Perl 5.10 feature. Won't it be nice when we can use those? Sorry my code is unusable by everyone else.)
I get shivers just thinking about how wonderful 2018 will be, the year of Perl 5.10.
If you listen carefully you'll hear the sound of thousands Pointy-Hairy Bosses printing this post in joy ;)
I find I have a lot to say whenever you talk enterprise and Perl. So much so, that I just wrote an article myself to address it.
http://yaketyhack.blogspot.com/2011/05/perlbrew-to-rescue.html
In summary of my post: Enterprise handling of Perl through back-patching is good (for sys-admins), and needed, but caused many problems for developers. App::perlbrew is very useful in that it allows for the easy separation of administration and development requirements and goals.
Oh, and no matter how much you rail against enterprise OS back-patching Perl, I don't believe you think it's the evil you make it out to be. ;) Then again, starting the discussion is often harder than participating in it, and you are quite good at starting the discussion (which is why I'm an avid reader).
There is also the excellent CPANTesters project which will test your distribution against a wide variety of Perls/Platforms. If you want 5.8.x to be well-supported it would be a nice gift to the community if you could run a smoker :)
http://wiki.cpantesters.org/wiki/QuickStart
I admit, it seems like it should be possible to install perlbrew on RHEL and CentOS installations, but apparently it isn't. (If it were, we wouldn't be having this discussion.)
Apparently using anything other than the system Perl 5 violates your warranty or terminates your support agreement or causes rickets or something. That's a real shame. I will miss having the name of the variable in the use of undefined value warnings.
Perlbrew is in the EPEL repository for RHEL/CentOS 5 and 6, and itself installed fine. It's trying to install Perl 5.13.6 as I type this. I assume since it's in the EPEL repo proper, and not the testing repo, it will be functional. It isn't listed as available for RHEL 4 based systems, but it should be *ossible* in a supported manner as there is an available 5.8.8 Perl package set for RHEL 4 based systems through the RHWAS, which CentOS packages in centosplus (assuming it's a Perl 5.8.5 version problem that prevents EPEL from packaging it). Then again, due to the nature of what perlbrew is and does, I think it should have the smallest set of Perl dependencies possible.
P.S. Yes, the 5.8.8 Perl for RHEL4 is fully supported by them. It's part of their Web Application Stack (http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/RHWAS/SRPMS/), which includes newer (at the time) versions of many popular LAMP components. It's a wonderful feature of RHEL4; I wish they had offered something similar in the 5 series (the supported php53 packages in the latest point release are as close as we'll get, I suspect).
If perlbrew really were available for enterprisey distributions, we wouldn't have to beg for people to donate their time supporting dozens of stable releases of Perl 5 for the next seven to ten years. What a lovely dream.
Putting a more serious hat on (let's say with some System Engineer's and Architect's consideration) I think there are two FAIL scenarios:
- "Let the developers supply everything. Let development call the shots. Use whatever library you like and whatever version you like. Live in the bleeding edge."
This will explode badly in your face at the worst possible time and it will be difficult to fix (and impossible to fix fast). Yes, perlbrew as production environment falls in this category. It's fine for development, or if production is an odd server, but NOT for datacenter wide development.
- "Follow dogmatically the sysadmin credo of "use only system packages supplied by the OS vendor".
This will not explode in your and will actually work, but it will be extremely painful at best. You'll miss years-old *stable* features like for example in Solaris 10 things like Perl 5.10, Moose and Java 6.
A solution to this problem when you don't have the time or money to upgrade your OS every six months are policies that fix the technology used by projects and provide a timeline for technology upgrades and updates. Also crucial are System Engineers with the knowledge --and time-- for building OS-native packages for these technologies. It costs money, but we are talking about enterprise here. Even the salaries in question are laughable when compared to the license you will be paying for things like Oracle database licenses or SAS contracts.
C.
As a module author I can live with enterprisey people sticking to older versions of my modules, which might or might not get enterprise support from RedHat et. al.
If they stick to old perl, why not also stick to old perl modules?
The solution for the Developer vs SysAdmin problem is to have two separate environments on the server, and have a clear update policy for each. There's the core OS, which is updated through the vendor provided packages, and there's the application root, which has it's own update method. Perlbrew can fit well within the update policy for the application root, while not stepping all over the system files.
Building native packages is essential, but IMO it's important that locally built packages not supersede native OS packages (unless there's a really good reason). Building a package to replace the system Perl is only slightly better than compiling it on the system. Better would be a package that installs it in a non-conflicting way similar to perlbrew.