I maintain a few modules. Most of them are simple but one relies on quite a complex stack of other modules, being essentially a wrapper module.
My home systems are running Perl 5.10.0 as that's what comes with Debian Lenny. Yesterday I thought it best to try and create environments with Perl 5.8.8 and 5.6.2 on them so I could test the code on older Perls. I can not get the same level of coverage that CPANTester provide but I can weed out the worst bugs in advance.
Using VirtualBox I installed some older system inside a VM container and tried stuff out. Perl 5.6.1 era systems are a nightmare, not only is Perl old, but all the supporting libraries are old and the Perl modules my module is dependent on will not install because the overall antiquity of the system.
If you had an older system (RedHat 7 era) box that has been patched over the years it's possible to get partially there as some elements of the dependency stack are present, though at older levels. On a new system it's almost impossible to install anything as the more recent versions demand newer libraries that just aren't there...
Is it worth trying to support Perl 5.6.x...?
As the saying goes, "You're doing it wrong". Simply install the other Perl versions under
perl -w Makefile.PL && make test # Run tests using the stock Perl
/opt/perl/bin/perl5.6.2 Makefile.PL && make test # use 5.6.2
/opt/perl/bin/perl5.10.0 Makefile.PL && make test # use 5.10
I guess you could even write a plug-in for Module::Release to check the tests on a list of Perls (or even all Perls under
Re: Perl 5.6.x
ajt on 2008-06-26T15:08:44
I have tried that in the past, as you say INSTALL suggests how to install Perl on a box in a different location. However what I found was CPAN got confused and modules from the different Perl versions got screwed up. I know it's supposed to work and it it did on my box for a while but once it' started going screwy I thought it best to put the other version of Perl in it's own space where it can't screw anything up with the vendors standard version.
At the same time I also wanted to test in a complete comparable environment, so I've got Perl 5.6.1 on Red Hat Linux 7.3 and CentOS 2.1 to play with. Who in their right mind would run Perl 5.6 on a modern system?
Perhaps I'll try again with Perl 5.6.2 and 5.8.8 to see if I can get them to coexist with vendor supplied 5.10 on my Debian Lenny box.
Wrong Minds
chromatic on 2008-06-26T17:17:18
Who in their right mind would run Perl 5.6 on a modern system?No one, which is why it makes so little sense to support them with new code.
You're talking about people who refuse to update their software. Their defining characteristic is that they refuse to update their software. Thus it makes little sense to me to offer them new versions of software for them not to upgrade to.
However, the longer answer is that it depends. A discussion that keeps cropping up is whether older perls are applicable anymore. My suggestion would be that if you're testing on an environment that had a version of perl packaged with it, then test that and later versions only on that envirnoment. However, with some environments (e.g. Windows) that don't come pre-installed with Perl, then take your starting point from 5.6.1.
The reason being that some environments have different configurations than earlier versions that were pre-installed with older perls, and as such you're not really testing how a real user would experience the testing on that earlier version of Perl.
For Windows users, the earliest current version of Perl still available from Active State is 5.6.1, so anything earlier is pretty pointless.
Manufacturing environments is something I'm planning to address within CPAN Testers in the coming months, as we should be testing what is reasonable in the real world, not what we think might be possible.
Re:Simple Answer: Yes
ajt on 2008-06-26T15:28:45
I'd like to support 5.6 and 5.8 even though I'm developing on and only now use 5.10. It's not as if I'm taking advantage of many 5.8 features let alone 5.10. Debian Sarge and Etch both came with 5.8.x and Lenny will come with 5.10, so to find a 5.6 system you need to go back to Woody - which is well past it.
At work I keep three Red Hat 7.x system alive (though I shouldn't really) and they use Perl 5.6, hence my plan to try and look at Perl on a system of that vintage.
Windows is a different story. I suppose people tend to install ActiveState Perl and don't upgrade until they do their periodic Windows reinstallation. At the same time it's a pain to install quite a lot on Windows because most people don't have a compiler so they either don't install the package or install a binary PPM.
Re:5.6?
chromatic on 2008-06-27T19:13:27
I can't think of anything in 5.8 that's radically new (e.g. given/when, dor).
Working Unicode, more and updated core modules, bugfixes, much better testing....
Re:5.6?
educated_foo on 2008-06-27T20:59:47
I mean nothing "radically new" in the sense that it makes your module totally unusable on an older Perl without. For example, I recently wanted to try out Parse::Marpa, but the author uses given/when all over the place. This makes it unusable without 5.10, without providing additional functionality (and with a marginal-at-best improvement in readability).New core modules? They're on CPAN. "Working" Unicode? Great if you need it (I don't), but the interface hasn't changed, has it? Testsing and bugfixes? I have a lot of code that worked just fine on 5.6, and while I now develop on 5.8, I find that I rarely trip over version-specific bugs.
Re:5.6?
chromatic on 2008-06-27T23:54:07
New core modules? They're on CPAN.
Many are, but at some point CPAN authors really ought to be able to say "I (added a new feature to|fixed a bug in) Perl 5 years ago; I'm finally going to take advantage of it in code."
Users oughtn't expect to run the new shiny on ancient installations.
Re:5.6?
educated_foo on 2008-06-28T02:40:02
Yes, and as a module author you can always tell your users to go fuck themselves at any point. I polish and publish some of the code I write because I hope it can also benefit others, and it can hardly do that if it doesn't work with their versions of Perl. It already takes extra time to get from "works for me" to "works for other people (e.g. documentation), and "works on older Perl" is a minor effort compared to this.Re:5.6?
Aristotle on 2008-06-28T00:14:25
Unicode support is a deal-breaker as far as I’m concerned. That the interface superficially hasn’t changed doesn’t matter – it didn’t work prior to 5.8. The identical interface means I don’t have to change my code to make it run and fail to work properly on 5.6. Uhm, hooray.
Re:5.6?
educated_foo on 2008-06-28T01:51:06
No, it means that you don't have to change your code to make it work all the time with ASCII or Latin-1, and a lot (or at least some) of the time with Unicode.Re:5.6?
ajt on 2008-06-28T09:37:29
Working Unicode is a bonus if you are dealing with XML as I am.
However in my situation it's the dependency stack that is a pain, while you can install the dependencies over time on an antique system there comes a time when some of the modules just won't install/upgrade any more. This means that on a brand new 5.6.2 installation it's plain impossible to actually install the dependency stack from CPAN, you have to figure out which older versions of some modules will install and install them one at a time manually. This makes testing on a vanilla 5.6.2 system awkward...
While I'm not going to take advantage on any new non-backward compatible features in 5.8.x I'm going to drop support for 5.6.x on some modules as I can't test it properly any more. People are more than welcome to send patches and such but it's not something I can very easily work on.
Re:5.6?
drhyde on 2008-06-30T13:48:00
If you want access to a 5.6.2 system for testing, drop me an email and I'll send you the details for a guest account I have for authors to get at one of my CPAN-testing systems.Re:5.6?
ajt on 2008-06-30T19:21:18
As every thanks for the offer but in the end I got two 5.6 era systems up and running. If I do need access to them what ago of OS are they running? My 5.6.x systems are by their nature antique.
Re:5.6?
drhyde on 2008-06-30T20:21:09
Debian 4.0. I could also build it on FreeBSD 6.2 and OS X 10.4 if you need. I believe that all of those are now the last-but-one version.
Re:You don't owe the users anything
ajt on 2008-06-30T19:30:21
I know but I also care...
