On 16 Mar 07, at 2:55 AM 16 Mar 07, Brett Porter wrote:
-1, at this point. I'd like to look at some specific test cases to
see how badly it might break a build - so I could be convinced.
No matter how bad the existing behaviour, it is consistent once in
place.
It's not consistent at all. It is totally erratic behavior,
completely defective and counter intuitive. All people are forced to
do is is continually override dependencies in child project to get
the right version.
I think it's unacceptable to drop this into a .0.x release, no
matter what the release notes say. Even if it makes it better for
new builds, the people that have their current one mysteriously
break will be rightly livid. I think we suffered this a little
earlier when we enforced order when it wasn't deterministic - I
think this would be more confusing than in that instance.
All it will do is allow people to align all the versions from the
parent POM. With MNG-1577 they can stop doing this. Mike has seen
this in action in his builds, and I just corrected a build in what
seemed a hopeless situation with the new behavior. There's nothing
consistent about the current behavior, it's actually harmful.
Our users must be able to trust point releases are safe upgrades.
Let's start moving on putting out 2.1 milestone releases instead.
I think this is a mistake and doesn't help our users. We have not
only the ITs (which are still not good enough but ...) Patrick made
an extensive set of tests plus we have users who have been watching
this issue for a year and can attest in the field to this being a
miserable situation. This is a solution to their problem.
Jason.
- Brett
On 16/03/2007, at 11:33 AM, 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.
Jason.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
