I agree (already voted) but which is easier to defend? A user who gets upset that giving them more control broke their build (but is easy to fix) or constantly telling people who assume the new functionality that the need to turn it on? Won't they be even more annoyed that it wasn't until they debugged the problem that they found out it was already fixed, it just wasn't enabled?
-----Original Message----- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 10:33 AM To: Maven Developers List Subject: Re: [vote] MNG-1577 as the default behavior I'm +1. I don't think that making dependencies in Maven more predictable or deterministic can wait for 2.1, especially considering that it has a fairly lengthy road before it gets to 2.1-final. Currently, what we have in place seems buggy, whatever the reality, so I don't see it as worth defending as a feature of 2.0.x. As others have pointed out, any broken builds caused by this should be easy to fix, since the builder now has much more - not less - control over his build. -john On 3/16/07, Patrick Schneider <[EMAIL PROTECTED]> wrote: > > +1 (non-binding) > > > Our integration tests are way too simplistic to test this so we > definitely > > need to test this against 'real life' complex builds. > > FWIW, we have been using this patch on our 60+ module build for two > months or so, with extensive use of demMgmt/transitive dependencies > exercising the new behavior. > > > Patrick > > On 3/16/07, Kenney Westerhof <[EMAIL PROTECTED]> 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]
