On 3/16/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Carlos Sanchez wrote:
> now poms in the repo that have dependencyManagement sections will
> start to change the behavior of current builds and people with 2.0.5
> will get very different results than people with 2.0.6 which i don't
> think it's acceptable for 2.0.x
How? a pom in the repo with a depMgt section will only affect it's own
dependencies, not the project depending on that pom in that repo.
If it didn't already specify a depMgt it will be unpredictable, and if it does,
then this change has no effect, since to fix a transitive dep's version
the dependency has to be specified in that pom too; so it'll contain both
a depMgt _and_ a dependency.
you have to make dependencyManagement transitive, if i publish B
depending on C saying in the depMng that C must be 2.0, A depending on
B has to get that C, so you need transitive dependencyManagement
So we've established that this bugfix is something we want and it should go in
2.1, 2.2 etc. So why try to support the unpredictable behaviour in 2.0.x?
I simply cannot understand how we can make 2.0.6 or newer behave in the same
unpredictable way (the case where the dependency is NOT specified to override
the depMgt section). That's just unsupportable.
I don't think it's unpredictable at all, counter intuitive sure, but
not unpredictable.
It's not acceptable for 2.0.6 to have a very different behavior than 2.0.5
my 2 cents
-- Kenney
>
>
> On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>>
>> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
>>
>> > I agree with Brett, this is a 2.1 change, not a 2.0.x
>> >
>>
>> Do you fully understand what the current behavior is and what this
>> patch fixes? You are essentially condemning users to complete
>> unpredictability. I really think that a build should be staged and
>> explain to users what the change is and let people build with it. If
>> we don't get enough feedback or there is a consensus that they think
>> it's not good then we don't put it in. But we already have many users
>> who are suffering and asking for this to be the default behavior.
>>
>> Jason.
>>
>> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
>> > get an earlier 2.1, i though we were going to do it anyway.
>> >
>> >
>> > On 3/16/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>> >> On 3/16/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>> >>
>> >> > Our users must be able to trust point releases are safe upgrades.
>> >> > Let's start moving on putting out 2.1 milestone releases instead.
>> >>
>> >> Agreed. On the other hand, most others seem to consider this
>> >> change important.
>> >>
>> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
>> >> satisfy all.
>> >>
>> >> Jochen
>> >>
>> >> --
>> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
>> >> whether
>> >> these will be used to run Emacs or the other way round.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>> > --
>> > I could give you my word as a Spaniard.
>> > No good. I've known too many Spaniards.
>> > -- The Princess Bride
>> >
>> > ---------------------------------------------------------------------
>> > 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]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
