[EMAIL PROTECTED] wrote on 08/10/2006 12:28:36 AM:
> If I understand your recommendation correctly, you would like me to
declare
> my dependency on version "[1.7.0,)" instead (meaning "version 1.7.0 or
any
> later version"). From a QE perspective, that is an untestable assertion
--
> there is no way to know that some future version of BeanUtils might
> introduce some incompatible change that makes *my* library no longer
work.
> That is not acceptable to me as the supplier of a library, because it is
> *me* who is going to suffer the "you *said* it would work" bug reports.
Craig, please don't ruin my fantasy world with your reality. :-) You are
right, in a perfect world you could depend on libraries keeping backwards
compatability but even then each project can have a different versioning
policy and their dependents would have to understand and codify that policy
in the version range, e.g., for commons-logging, should the version range
be "[1.0,1.1)" or "[1.0,2.0)"? This is not realistic.
> If an end user of my library wants to override my setting, they can
> (although making them do it in every leaf node is definitely a violation
of
> the "don't repeat yourself" mantra that M2 seems to really like :-). But
I
> want *my* POMs to advertise what *I* have tested, and not rely on all of
my
> dependencies not to break me with future versions. I wouldn't even want
to
> trust my own modules enough to use ranges like that :-).
I like your idea about dependencyManagement able to override transitive
versions. To me that's the best idea because you are listing your own
versioned bill of materials for your system to test with. This is critical
- we have seen numerous instances where versions suddenly devolve due to
the addition of a new dependency. That's unacceptable and having a master
list of dependency versions in a single place would solve the problem.
mike
