Personally, I've ditched the idea of having "one central version" and have an (identical) $VERSION in every module of a distribution. I use Perl::Version resp. the perl-reversion script there to bump the version number in all module files at once.

UPDATE: I think I have a patch which works...

---

---

Thanks for showing me perl-reversion! It's nice, but I can't convince it to replace the version in one of my t/*.t test files. I'm using the format straight out of Test::More:

 BEGIN { use_ok('Some::Module', 1.02) }
[download]

I don't see any relevant RT issues open for it. I'll keep staring at the code to figure out why, but if you happen to know of a workaround, please let me know.

I don't think it looks for arbitrary numbers. Reading through the source, it seems to look for things like VERSION followed by something that looks like a version number.

I guess a good workaround could be to use:

BEGIN {
    my $VERSION;
    $VERSION = 1.02;
    use_ok('Some::Module', 1.02);
};
[download]

... but then, I'm not sure what the use of use_ok is anyway. The test will crash if use_ok fails, but if it fails, there is little sense to continue anyway :)

Just tell reversion where to search:

perl-reversion .
[download]

If it finds too much, be more specific about the version you want to change:

perl-reversion --current 1.02 --bump
[download]

Or search only some directories

perl-reversion t lib
[download]

etc.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

thanks, that's a good tip for consistent versioning which would at least allow PREREQ_PM to specify the "real" PDL-linked dependency, not sure it would help with the compilation/linking issue though, which is hard to test (indirectly via cpan smokers) without uploading a ton of miniscule changes to CPAN.

I don't know if this'll help at all with your wanting to do incremental testing, but I started using Travis CI for build tests prior to uploading to CPAN to let a wider range of test platforms have at it. In doing this, I minimize to the best of my ability not uploading something to the CPAN that will fail because of something stupid, making publicly available a broken module, and taxing the CPAN Testers for nothing.

Just put your code on Github, sign up for Travis-CI, create a .travis.yml file in your distribution's root directory (example contents below), and then with every push, you get testing on a wide range of perl versions, across Mac and Linux (no Windows unfortunately... I have two Strawberry Perl VMs I test my modules on manually prior to upload to CPAN).

This is an exact working copy/paste of a .travis.yml file from one of my modules.

language: perl

perl:
    - "blead"
    - "5.22"
    - "5.20"
    - "5.18"
    - "5.16"
    - "5.14"
    - "5.12"
    - "5.10"

os:
    - linux

before_install:
  - git clone git://github.com/travis-perl/helpers ~/travis-perl-helpe
+rs
  - source ~/travis-perl-helpers/init
  - build-perl
  - perl -V
  - build-dist
  - cd $BUILD_DIR             # $BUILD_DIR is set by the build-dist co
+mmand

install:
  - cpan-install --deps       # installs prereqs, including recommends
  - cpan-install --coverage   # installs coverage prereqs, if enabled

before_script:
  - coverage-setup

script:
  - perl Makefile.PL          # or Build.PL if it exists
  - make                      # or ./Build
  - make test

after_success:
  - coverage-report
[download]

Here's an example Travis report on one of my modules. You can then drill down to each version of perl to see the test results themselves.

oops; apologies - the anon post was me --moocow