Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • As the saying goes, "You're doing it wrong". Simply install the other Perl versions under /opt/perl, just like the INSTALL [] says. That way, you can run your tests within one environment using all the different Perl versions:

    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 tes

    • 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 compa

      -- "It's not magic, it's work..."
      • 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

    • 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 supp

      -- "It's not magic, it's work..."
  • IMHO you should definitely support 5.8, since it's the default Perl on the latest (or recent) versions of many distributions. I'm not sure 5.6 is worth the trouble, but then again, I can't think of anything in 5.8 that's radically new (e.g. given/when, dor).
    • 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....

      • 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 bugfix

        • 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.

          • 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.
        • 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.

          • 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.
      • 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 manu

        -- "It's not magic, it's work..."
        • 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.
          • 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.

            -- "It's not magic, it's work..."
            • 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.
  • You're giving your code away and don't owe the users anything. While I am always grateful when authors support old versions of perl, I can't demand it. Support what you want to support, what's convenient for you, and then if you also accept patches for older versions, your users can't complain.