Re^2: Stop suggesting to upgrade perl

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