Re: Artificial perl version dependencies (backward)

[tye]

I have to disagree with the support for arbitrarilly including things like "use 5.008" into modules. It is not "the safe thing to do". If you don't know what version of Perl is required for your module to work, then the correct thing to do is to declare that you don't know by not specifying a minimum Perl version! I don't see much good in transforming "I don't know what Perl version this works in" into "I know that this doesn't work in Perl versions prior to 5.8".

I think a lot of people are misinterpretting "use 5.008" as "I guarantee that this works in Perl 5.008 and later". That isn't what the construct means. The only guarantee with "use 5.008" is that it dies when the Perl version is less than 5.008. So "use 5.008" means "I know that this doesn't work in versions prior to 5.008 so don't even bother to try using it there."

So please stop this annoying practice. And, if you do include "use 5.008" or such in your module code, then please have the courtesy to include comments noting which feature(s) you have used that make it so your module can't work in prior versions of Perl.

Update: And to prove this point, let us consider the real world and what happens when "use 5.008" is included or not in a module.

Say I write a module and don't go to any effort to figure out nor document what Perl versions it works with (and thus don't "use 5.008" nor declare a requirement for any other version of Perl) and then upload this module to CPAN. The CPANTS (the testers) will automatically download my module and try it on a bunch of versions of Perl. Someone wanting to use my module can look at the CPANTS reports in order to figure out which versions of Perl my module works with. In particular, they can likely see if my module works with their version of Perl without even having to download my module (so long as someone runs CPANTS on that version of Perl).

If, instead, I had included a "use 5.008" in my module for no good reason (because someone mistakenly thinks this is "the safe thing to do"), then all of the CPANTS reports for versions prior to 5.008 will fail with "Perl v5.8.0 required", telling everyone nothing useful.

In the better scenario, the potential user of my module gets useful information. They either get told that my module works on their (old) version of Perl and also get a module that just works for them. Or, they get told that it doesn't work and can drill down and see what error message(s) go along with that failure and can decide whether that looks like something that is easy enough to fix and they want to try to make the module work on older versions of Perl.

And I, as the module author, get useful information as well. When I check how my module is being received, I should note that it is failing some CPANTS tests and I can drill down into those and see why it is failing and maybe decide to make fairly trivial changes to my module that might make it work for more people.

At my work, we have Perl 5.6.0 installed everywhere. The benefit of having Perl everywhere is clear and so it was worth the effort to get Perl into our standard tools pack so that it got installed everywhere. The effort involved was not that great. So we have a clear benefit for fairly low effort.

Why haven't we upgraded Perl? Because the effort to replace every copy of Perl 5.6.0 with 5.8 is much more than the effort originally needed to get Perl 5.6.0 everywhere. And what benefit is there to 5.8 over 5.6.0 ? Almost none. We actually upgraded to 5.6.0 because we saw enough benefit in that case. Perls prior to 5.6.0 had problems that made upgrading more important. 5.6.0 works great for us.

It would probably be a good idea to put a fairly new release of Perl into our standard tools pack so that eventually a newer version of Perl will end up everywhere. However, there is risk associated with this so it isn't something we will do lightly. There is risk that upgrading Perl will break something that works on the old Perl. And, it is a pain to get the new Perl being pushed to all of our systems while making sure that the places where people write new Perl code only use the old version of Perl. If the new Perl got onto some developer's platform while Perl was only upgraded on some of the production systems, then we'd surely get a script written that appears to work fine and works fine on some production systems and then causes a bunch of headaches when it gets deployed to a system that hasn't had the new tools pack installed.

So it is a no-brainer to not update Perl yet. Too much effort and too much risk with dubious gain.

[itub]

I agree with most of what you say, but I think you are overestimating the "version diversity" of CPANTS. For example, for one of my modules that's been there for a while and has 34 test results, only one has a version < 5.8.0, and this was a lucky exception. ;-) Most of the test results are for 5.8.5 to 5.8.8. There is a bias towards bleeding edge versions among CPAN testers (I even have results from versions > 5.9.0).

[tye]

Yes, this crossed my mind but didn't make it into my text.

So long as the standard tools for creating modules are inserting "use 5.008" or such into every new module they help create, there is little point in CPANTS testers using older versions of Perl. I wouldn't be surprised if some CPANTS testers have abandoned using old versions because so many modules fail.

But I think a movement to remove these useless and annoying cases of "use 5.008" (as opposed to the few cases that are there for real and documented reasons) could motivate a CPANTS revival for older versions of Perl. It has certainly sparked my interest in setting up CPANTS for 5.6.0 and 5.6.1. I'm sure there will also be challenges in getting CPANTS running in such environments.

I'm also collecting the few, simple, fairly easy techniques that I use (or avoid) in order to keep my modules compatible with older versions of Perl. Perhaps even a perlage.pod...

[demerphq]

Maybe no 5.8; should mean "if you later on encounter 'use 5.8' then ignore it".

[ysth]

Perhaps even a perlage.pod

Sounds terrific. Care to post what you've got?