+1, I agree with Kenney that folk will be able to remove a lot of
workaround snippets from their poms,
the sooner the better.
Andy
On 16 Mar 2007, at 11:48, Kenney Westerhof wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
