in reply to Artificial perl version dependencies

What merlyn said, and: suppose the author decided to maintain a module from 5.8.x, and gets a note from you saying it happens to work on 5.6. Unless the author is willing to continue maintaining 5.6.x from now on, inspired by your check, there's no good way of proceeding. When the next version comes out, should the author wait for you to release? Note that "the author should test against older Perl" is no good, because if they were willing to do that, they'd already have done so!

One subtlety here is bundled core modules. The corelist for 5.8.x is both larger and has newer version numbers than the one for 5.6.x: if you test a module on an older Perl, you should test against a vanilla install, because otherwise you might not notice breakages. If a maintainer has several distros, and some in fact do rely on non-bundled prereqs, testing on multiple versions becomes tedious!

(Here's an idea for a project though: a chrooted environment that's easy to set up every time from scratch for testing distro releases.)

  • Comment on Re: Artificial perl version dependencies

Replies are listed 'Best First'.
Re^2: Artificial perl version dependencies
by eyepopslikeamosquito (Archbishop) on Dec 21, 2006 at 20:28 UTC

    Here's an idea for a project though: a chrooted environment that's easy to set up every time from scratch for testing distro releases.
    It's early days yet, but adamk is determined to solve this "Pain In The Ass" of a problem with his Perl Image Testing Architecture (PITA) project, where PITA::Driver::Chroot is currently marked as "speculative". (See also PITA CPAN module).