Hi Nadim, The difference is that Module::Build forces the Foo::Bar's author to work out what current versions of Some::Module and Other::Module are suitable and to try to predict what future version will still be compatible. This is time consuming and error prone (predicting the future isn't easy) and it has to be done for every module that requires these other modules. In fact I think most module authors do not test these things thoroughly - I know I don't, it's just too much of a pain.
If Some::Module and Other::Module used Version::Split for their version information then Foo::Bar's author could just say "well I developed it with Some::Module 1.23 and Other::Module 1.2 so only accecpt a version that is declared to be compatible with those". That way all the work on building the compatibility information is only done once and it's done by Some::Module and Other::Module's authors, which is good because they're the people who should know most about their own modules. Foo::Bar's author never has to change his requires just because Other::Module 1.9 has been released and works in a different way. You also get the interesting side effect that if Foo::Bar's tests all pass when using Some::Module 1.23 and they fail with 1.24 (which has been declared to be comapatible) then both Foo::Bar's and Some::Module's authors can be informed about it and try to work out who has the bug, F On Tue, Jan 27, 2004 at 08:54:47AM +0100, khemir nadim wrote: > Hmm, isn't that what Module::Build is already offering to you? > use Module::Build; > my $build = Module::Build->new > ( > module_name => 'Foo::Bar', > license => 'perl', > requires => { > 'perl' => '5.6.1', > 'Some::Module' => '1.23', > 'Other::Module' => '>= 1.2, != 1.5, < 2.0', > }, > ); > $build->create_build_script;My 2 cents, Nadim. > >