On 4/15/13 7:02 PM, Mike Doherty wrote:
> This requires Moose maintainers to know about all the things their
> releases break. Have you considered reversing the directionality so
> MooseX::Blah knows about the things which break it? That seems like a
> more likely scenario to me, and lets the right maintainer control the
> "conflicts" relationship.
It's a good idea to reverse the relationship. In this case it doesn't
work out.
* I believe that was the confusion at the Lancaster Consensus,
that conflict was a way to express "I can use Parent >= 1.23 but not
1.69". That is already covered by the "requires" relationship and
version ranges.
requires:
Parent: >= 1.23, != 1.69
* In order to find out what modules Parent conflicts with,
necessary when installing Parent, a CPAN shell would have to
iterate through every module's metadata. [1]
* Parent can test its dependents before Parent releases, but Child
cannot. Parent has the opportunity to test and
mark its conflicts at release time so at least CPAN shells can
protect users of Child from upgrading Parent and breaking Child.
[2]
[1] It would be nice if we had a reliable meta API for that, but we
don't at the moment.
[2] This should contain the assumption "in an automated fashion". Sure,
Parent and Child can keep in close communication with each other, but
this does not scale. When you're a heavily depended on module such as
File::Spec, Test::More, Moose, DBIx::Class, Module::Build,
ExtUtils::MakeMaker or version you simply have too many dependents and
are too many levels removed.
