Re: Stop suggesting to upgrade perl

[Tux]

I agree that you should not upgrade perl just for the upgrade, and - also - not because some wise monk tells you to without a reasonable reason. I do agree with the volunteer-time that chromatic mentions, but not with that being a reason to upgrade. He has been around long enough to know some problems do not have any issues in perl versions (other than maybe the updated documentation coming with it).

Nor are there any valid reasons to force anyone to move along to the *latest* version of perl. There may be very good reasons to upgrade, even with the problem at hand, but that does not imply a forced move from 5.6.1 to 5.18.1 where 5.12.3 might be more convenient.

Note however that perl releases are not made just for the release numbers. However the people in charge (the CEO's, not the perl5 developers) like to see the language alive and being actually developed, those updates have a reason: for most the updates are not because of the new features, but because of bug fixes. A lot of complaints that we as monks see pass by here do get fixed.

The example given by boftx is imho the worst example to have to opinion not to upgrade. I love defined-or to the extend that I have the feature available for *every* version of perl5.8.x. I can't live without it in my daily work. All production scripts use it. Though by now our production machines and all customers use 5.14.2 as a minimum perl. Also not that this seldom is one of the reasons mentioned in answers here where the OP is asked to upgrade perl, as this was a new feature in 5.10, not a bugfix.

A next thing I want to mention is related to what chromatic mentions in volunteer time use: the minimum version of perl for the toolchain support has been raised to perl-5.8.1 with an option to be raised to 5.8.4 is 5.8.1 proves to be too restrictive. This was done in the Lancaster Consensus. The reason is that it just takes too much time of the authors of the toolchain to be 5.6 compliant. Having a minimum version as guarantee can make code a lot more simple to write and to maintain. The toolchain however is used for EVERY module on CPAN. This causes the call to upgrade your perl to the minimal version of perl supported by the toolchain, as though your reported bug might not be a perl-bug or a CORE-bug, the bug might have been fixed in a newer release of the CPAN module, but you cannot install it, as the toolchain used to build and install the module does not work on your old version of perl.

[tobyink]

That the toolchain is switching to 5.8.1+ does not mean that people on 5.6 will no longer be able to install anything from CPAN. ExtUtils::MakeMaker has been bundled with every release of Perl 5, and the version that comes pre-installed with 5.6.x (EUMM 5.45 for Perl 5.6.(0|1) and EUMM 6.17 for 5.6.2) won't suddenly stop working.

If a Makefile.PL doesn't use any whizzy new EUMM features, it can thus happily continue to run on Perl 5.6. Even if it does; EUMM 6.72 can be downloaded and installed on Perl 5.6.x with no problems (perhaps EUMM 6.74 too, but no successful reports on CPAN testers yet).

So even though the toolchain is dropping Perl 5.6 support, people will be able to continue installing CPAN modules on Perl 5.6, provided module authors make the effort to support versions of Perl that old. The toolchain EOL is not the death-knell for Perl 5.6.

Personally there are very few of my CPAN releases I make the effort to support Perl 5.6 on. Type-Tiny and PerlX-Maybe are amongst them.

[Tux]

You are absolutely right. I also try to support 5.6.x for some of my modules. (I dropped 5.005_04 not too long ago for Text::CSV_XS). What you will see however, is that some modules will require new TESTING features, like Test::More's done_testing and subtests. These might require new(er) build tools and the snowball starts rolling.

I never stated that 5.6 would not be able to install new CPAN stuff, but that one should be aware that it will/might not work out of the box for many CPAN updates in the (near) future.

[boftx]

I suppose I should have put more emphasis the importance of the intended operating environment.

I am not opposed at all to running a reasonably recent version of Perl when possible. But it must be borne in mind that there can be considerable time and expense involved for a company to do this. I would be hard pressed to defend the practice of upgrading every time an even-numbered version of Perl came out.

Tools such as perlbrew make it simple for individuals, but even then, there can be problems if the process takes too long to run and the hosting server (if one is being used) decides to terminate the process. I had this happen to me when installing 5.16 and wound up doing it with --notest and then going back and running the tests manually just for sanity's sake. Part of the cause of this problem can be attributed to the ever-growing number of core modules, it seems.

I agree with the OP that just automatically saying to upgrade is not always the most practical solution. Unless the problem involved is the result of a bug that can only be properly rectified by an upgrade, I think it is better to suggest a solution that works on the version the requester has, if possible.

All this being said, I prefer having a recent, reliable version of Perl on a production platform when it makes sense to upgrade. I, too, like the //= operator a lot and use it regularly at work. But that by itself could not justify the expense of an enterprise wide upgrade when I was restricted to 5.8.8, and certainly doesn't justify (in my mind) requiring the use of 5.10 as a minimum version in a CPAN module.

[chromatic]

... certainly doesn't justify (in my mind) requiring the use of 5.10 as a minimum version in a CPAN module.

But it must be borne in mind that there can be considerable time and expense involved for a company to (run a reasonably recent version of Perl)...

You want CPAN authors who give away their code for free, largely in their volunteer time, to test their code against at least a dozen and sometimes as many as seventeen or eighteen stable releases because it's too expensive for a business to upgrade to a supported version of Perl? You object to me using features I personally added to Perl itself several years ago in my CPAN code because it's too expensive for your business to install a new version of Perl more often than once every five years?

I can understand why you might want that, but why would I do that?

[Tux]

Only 18? I test Text::CSV_XS with all supported perl versions ever released, both in threaded and unthreaded version on as many OS's as I have access to. That is currently over 120 builds and tests before I release.

External USB-drives work well for that purpose. I think in now has over 150 versions of perl installed for my laptop architecture.

What you did not mention however might be way more important with CPAN modules: testing on different architectures and operating systems. What works well on Linux is not guaranteed to work on Windows, NetBSD, HP-UX, AIX, MacOSX, AIX, or OpenVMS. What works well on i686 might not work on ia64, pa-risc, risc, or arm. It is impossible for CPAN authors to test every version of perl in any possible configuration on every supposedly supported OS and version thereof for there to be released module. Feedback is vital. CPANTESTERS is a big help, but no guarantee.

Next time when you hit a bug, consider doing some analysis yourself and post a patch in your RT ticket, so the author is able to improve portability.

[boftx]

Chromatic, your post deserves a well thought out response which, at the moment, I am too tired to properly compose. I will read this again and attempt to give it the justice that you so justly deserve. Please be patient with me.

UPDATE

I suspect that it is often the case that those who write the code at a company don't have as much control as they would wish for what platform is in use or how upgrades are scheduled. And while you might be justifiably perturbed about companies that use expense for a reason to not upgrade for a very long period of time, it is not unreasonable to go three years or so. (Yes, five is stretching it even for me, but I have seen it on more than one occasion.)

On the other hand, I would not be surprised to find employees of those companies contributing to CPAN in an effort to pay-it-forward. I know that I have tried, and have seen others do so at every company I have been associated with for the last 15 years.

Oh, we mustn't forget that in many cases it is simply that someone is following the age-old adage that if it ain't broke, don't fix it. :)