I think it won't break builds at all.
I think that people have lots of workarounds in their poms right now
to overcome this problem - specifying transitive dependencies directly,
which they don't directly use, but just to enforce that version being used. I've
done so myself quite a few times. Those builds will not fail since the
extra dependency will be redundant.
What could be a possible usecase where a build will break?
I agree with the fact that we need to test this thorougly.
Our integration tests are way too simplistic to test this so we definitely
need to test this against 'real life' complex builds.
The best way to do that I think is to apply it to 2.0.x and let people test it
on their builds for a while.
If it's breaking more than it fixes we can always roll back before the release.
-- Kenney
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. 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.
Our users must be able to trust point releases are safe upgrades. Let's
start moving on putting out 2.1 milestone releases instead.
- 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]
