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.
> 
> 

Reply via email to