Dist::Zilla::TravisCI::MVDT - FAQ for Minimum Version Dependency Testing (MVDT)
MVDT stands for "Minimum Version Dependency Testing". This is a stress test of your prereqs that tests the absolute lowest version of your prereqs that they said they would be able to use. This includes all of those un-versioned dependencies. If your prereqs said that it'll work with any version of Moose, then MVDT will test using Moose 0.01.
Because your prereqs are a commitment to what versions work and what doesn't from within your tool. Far too often, the prereqs end up being un-versioned, and the assumption that any version of a module will work is typically inaccurate.
Can you claim that the very first CPAN release of Moose will work just fine with your fairly modern module?
that's exactly what your prereqs said,
if you used Moose and didn't tie a version number to the
And if the prereqs are inaccurate, you're going to get bug reports that your module doesn't work because of some weird error. And it's likely going to take a lot of debugging before you figure out that the user should upgrade module X.
Probably not, but we can't accurately say what version people will have. What we can accurately say is that a certain percentage of the users will NOT have the latest version. In fact, in most cases and especially with popular "release often" modules, a large majority won't.
Some may have modules that are 2-5+ years old, since it came with Perl core, or came with the operating system's package of Perl (or some other module), or came as a dependency for some module they grabbed from CPAN several years ago. You can't tell. The only thing we can tell is what the prereqs recommend.
Some users prefer to download as little from CPAN as they need to, and keep their Perl requirements in the same place as their OS requirements. For example, Debian's apt system has thousands of Perl modules, with all of the proper requirements and dependencies, thanks to the Debian Perl Group's work to translate those Perl modules to Debian packages. This keeps OS dependencies clean and makes upgrades seemless.
By maintaining accurate minimum prereqs, you can find a good happy medium between making sure your module works for the right version ranges, and not promoting overly restrictive version requirements.
Because a CI environment is the perfect testbed to install old versions of modules without affecting your work environment or anything else. Travis CI is an especially good choice because of the way they use "throwaway VMs" and Perlbrew.
Well, a lot, actually. I won't lie; MVDT can be a royal pain-in-the-ass. You will be going through a lot of cycles like this:
* Start a chainsmoke * Wait for TravisCI to start and finish your testing * Try to identify the offending module dep * Try to figure out which version it should be elevated to * Add/change the module version in your code * ...repeat, repeat, repeat...
However, both TravisYML and this guide will try to help you out as much as possible.
In the end, yes. Remember that the hard part is going to be the first time you go through it. The real reward is AFTER you finish through that initial stage and finally get a working PASS from Travis CI WITH MVDT turned on. You should keep MVDT on at that point, and it will continue to check that your code is working under the bare minimum modules.
Let's say at some point you have a need for the
first_index function from List::MoreUtils. Beforehand, you were just using
uniq. So, you had your
use statement set to
List::MoreUtils 0.10. But, List::MoreUtils didn't introduce
first_index (as an alias of
However, the TravisCI chainsmoking found the problem. (Provided that you're actually testing that portion of the code...) You get the failure, fix the version problem, and catch it before it's released. And that's probably one less bug report you'll get.
Your first steps should be as follows:
topic/mvdt, rebasing the huge batch of commits into one, and then merging it into master.
dzil chainsmoke --mvdt. The
chainsmokecommand was practically designed for MVDT.
First, identify the module. The chances are good that the error message is of the
Can't locate object method variety. If not, then something within the module or object will complain. If you don't recognize the module as a prereq of yours, you may want to litter your tests with Devel::SimpleTrace or similiar to ensure that the failures give you a full path. Something in that path has to be the module failure point.
Now, you'll need a better version to use. Check BackPAN and MetaCPAN. If you're lucky, the module doesn't have that many versions and you can just try the next one up. If not, there are some ways of figure out where to go next:
Commit that change and re-run the
The project homepage is https://github.com/SineSwiper/Dist-Zilla-TravisCI/wiki.
The latest version of this module is available from the Comprehensive Perl Archive Network (CPAN). Visit http://www.perl.com/CPAN/ to find a CPAN site near you, or see https://metacpan.org/module/Dist::Zilla::TravisCI/.
Brendan Byrd <firstname.lastname@example.org>
This software is Copyright (c) 2013 by Brendan Byrd.
This is free software, licensed under:
The Artistic License 2.0 (GPL Compatible)