On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:
Jason van Zyl wrote:
Hi,
After working with it a little this week I would like to propose
to make MNG-1577 behavior introduced the default. Builds are
completely and totally unpredictable without this behavior. The
behavior in 2.0.5 is fundamentally broken. To are totally prey to
any dependency introduced by a dependency which makes no sense and
completely counter intuitive. I stabilized a massive build this
week simply by using the behavior present in the 2.0.x branch. I
don't think we're doing anyone any favors leaving the old behavior
in. After watching a disaster be recovered by using this new
behavior I feel that the patch should go in as is and become the
default behavior. This puts the user in control which is the way
it should be.
I propose we make this the default behavior. Can anyone think of a
case where this degree of control would break an existing build?
This patch saved my bacon this week, I think this behavior makes a
world of difference to users.
It seems that this discussion has settled down by now and I'm fine
with the conclusion you guys have come up with.
However, I would like to make one point. I see that the discussion
has been confused with
silly/dump/whatever dependency resolution
vs
silly/dump/whatever, but *predictable*, dependency resolution.
If this patch would in any way change dumb, silly, retarded,
awkward *predictable* dependency resolution I would have voted -1
to it.
It's entirely not predictable. Anyone asked how they thought depMan
works would answer in accordance with the work in MNG-1577. They do
not expect the behavior that is there before it.
We cannot change the behavior in a bugfix release, no matter how
trivial and "sane" it will be. We just can't do it. Adding an
option to enable the good method would be a way around, and it
*might* be done in a 2.1 release as it would make life better for
everyone, but even then we're violating the rules of never changing
behavior.
I would like comments on this *philosophy*, not the issue in question.
In theory I would agree. But we've gone against this several times.
A workaround for this would be to change the XSD and say that the
XSD specifies the behavior which is the only thing that makes sense
to me. The model version should imply behavior.
The problem here is that a static model cannot imply the behavior of
a dynamic system.
In this case the XSD would be exactly the same would describe nothing
regarding how one dependency is selected over another. The static
model cannot reflect dynamic nature of artifact resolution.
Unless you are referring to something in the model which said what it
was going to do and as we discussed (Ralph brought it up) that it
would be a maintenance nightmare. What we would ultimately have to
express in this case is that we were wrong and not providing the
behavior that anyone expects and that we had corrected it. Cumbersome
instead of providing a default mechanism that does the right thing.
In this case we're fortunate that it will bring far more benefit then
harm. I think we've done the right thing in this case and the result
will be users will be better off.
Jason.
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
