<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">Ever have to give up using a new, really useful feature in Perl 
because someone on Centos uses 5.8?

Not sure what will work with PerlBrew if you have five versions 
of Perl installed with your modules?

No longer. Now you Makefile.PL can use the correct Perl Version.

This started when I wanted to upgrade FindBin::libs and couldn't 
because too many users were stuck on 5.8 (or 5.00503!). I didn't
want to check $^V every time the thing ran, the installed Perl
version isn't going to change with each run. So I copy the 
a version of the module for $^V &lt; v5.9 and have antoher one
that uses newer features.

Upgrading *that* one runs afoul of users on v5.16... Egads! Time
for a module.

Basic use:

(1) Your source code goes into a perl-version-specific directory:

    ./version/v5.8.8/bin/...
    ./version/v5.8.8/lib/...
    ./version/v5.8.8/t/...

    or into Git with tags like

    perl/v5.24
    perl/5.005003
    perl/5.005_003


(2) Your Makefile.PL (or Build.PL or whatever) does a:

    use Module::FromPerlVer;

    use Module::FromPerlVer qw( use_dir 1 );    # copy from dir
    use Module::FromPerlVer qw( use_git 1 );    # checkout with tag
    
(3) The contents of your install directory are populated
    via bulk copy from ./version of the higest version 
    number not greater than the Perl used for installation
    or checkout of tag for the higest version.

For regression testing of current modules with older versions
of Perl you can pass ( perl_version =&gt; X ) to ignore $^V and
run the code as if the perl's v-string is X.

 
</pre></body></html>