Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior

[Trygve Laugstøl <tr...@apache.org>]

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.

It seems that this discussion has settled down by now and I'm fine with 
the conclusion you guys have come up with.

However, I would like to make one point. I see that the discussion has 
been confused with

  silly/dump/whatever dependency resolution

vs

  silly/dump/whatever, but *predictable*, dependency resolution.

If this patch would in any way change dumb, silly, retarded, awkward 
*predictable* dependency resolution I would have voted -1 to it. We 
cannot change the behavior in a bugfix release, no matter how trivial 
and "sane" it will be. We just can't do it. Adding an option to enable 
the good method would be a way around, and it *might* be done in a 2.1 
release as it would make life better for everyone, but even then we're 
violating the rules of never changing behavior.

I would like comments on this *philosophy*, not the issue in question.

A workaround for this would be to change the XSD and say that the XSD 
specifies the behavior which is the only thing that makes sense to me. 
The model version should imply behavior.

--
Trygve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior

[Trygve Laugstøl <tr...@apache.org>]

Jason van Zyl wrote:
> 
> On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:
> 
>> 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.
>>
>> It seems that this discussion has settled down by now and I'm fine 
>> with the conclusion you guys have come up with.
>>
>> However, I would like to make one point. I see that the discussion has 
>> been confused with
>>
>>  silly/dump/whatever dependency resolution
>>
>> vs
>>
>>  silly/dump/whatever, but *predictable*, dependency resolution.
>>
>> If this patch would in any way change dumb, silly, retarded, awkward 
>> *predictable* dependency resolution I would have voted -1 to it.
> 
> It's entirely not predictable. Anyone asked how they thought depMan 
> works would answer in accordance with the work in MNG-1577. They do not 
> expect the behavior that is there before it.
> 
>> We cannot change the behavior in a bugfix release, no matter how 
>> trivial and "sane" it will be. We just can't do it. Adding an option 
>> to enable the good method would be a way around, and it *might* be 
>> done in a 2.1 release as it would make life better for everyone, but 
>> even then we're violating the rules of never changing behavior.
>>
>> I would like comments on this *philosophy*, not the issue in question.
> 
> In theory I would agree. But we've gone against this several times.

When?

In this case there was talk about changing behavior that would 
potentially break existing builds as it wasn't determined if it was 
predictable or not.

>>
>> A workaround for this would be to change the XSD and say that the XSD 
>> specifies the behavior which is the only thing that makes sense to me. 
>> The model version should imply behavior.
> 
> The problem here is that a static model cannot imply the behavior of a 
> dynamic system.
> 
> In this case the XSD would be exactly the same would describe nothing 
> regarding how one dependency is selected over another. The static model 
> cannot reflect dynamic nature of artifact resolution.
> 
> Unless you are referring to something in the model which said what it 
> was going to do and as we discussed (Ralph brought it up) that it would 
> be a maintenance nightmare. What we would ultimately have to express in 
> this case is that we were wrong and not providing the behavior that 
> anyone expects and that we had corrected it. Cumbersome instead of 
> providing a default mechanism that does the right thing. In this case 
> we're fortunate that it will bring far more benefit then harm. I think 
> we've done the right thing in this case and the result will be users 
> will be better off.

Ok, using the model version is quite possibly wrong but there 
could/should be a field indicating the expected behavior making room for 
these kind of changes. An alternative is to take a look at the required 
Maven version to use that as pointer to which behavior to use.

Leaving the specifics of this issue, imagine what will happen if the 
plan of very frequent (<1 month) release intervals will be implemented 
and within the next two years there will be 20 Maven releases (all most 
likely with 2 as it's major version). If the behavior suddenly changes 
randomly between point releases people will suffer way more as everyone 
in a team has to standardize on a certain Maven version and then we've 
suddenly lost a lot of the things we wanted to gain by putting a version 
field on everything. By having such a high number of releases you can be 
sure people will use the different versions all the time.

I cannot stress the need to keep the behavior *very* stable. A dump (but 
not wrong) choice made by a developer should not be allowed to suddenly 
break (clumsy) but working builds.

--
Trygve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior

[Jason van Zyl <ja...@maven.org>]

On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:

> 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.
>
> It seems that this discussion has settled down by now and I'm fine  
> with the conclusion you guys have come up with.
>
> However, I would like to make one point. I see that the discussion  
> has been confused with
>
>  silly/dump/whatever dependency resolution
>
> vs
>
>  silly/dump/whatever, but *predictable*, dependency resolution.
>
> If this patch would in any way change dumb, silly, retarded,  
> awkward *predictable* dependency resolution I would have voted -1  
> to it.

It's entirely not predictable. Anyone asked how they thought depMan  
works would answer in accordance with the work in MNG-1577. They do  
not expect the behavior that is there before it.

> We cannot change the behavior in a bugfix release, no matter how  
> trivial and "sane" it will be. We just can't do it. Adding an  
> option to enable the good method would be a way around, and it  
> *might* be done in a 2.1 release as it would make life better for  
> everyone, but even then we're violating the rules of never changing  
> behavior.
>
> I would like comments on this *philosophy*, not the issue in question.

In theory I would agree. But we've gone against this several times.

>
> A workaround for this would be to change the XSD and say that the  
> XSD specifies the behavior which is the only thing that makes sense  
> to me. The model version should imply behavior.

The problem here is that a static model cannot imply the behavior of  
a dynamic system.

In this case the XSD would be exactly the same would describe nothing  
regarding how one dependency is selected over another. The static  
model cannot reflect dynamic nature of artifact resolution.

Unless you are referring to something in the model which said what it  
was going to do and as we discussed (Ralph brought it up) that it  
would be a maintenance nightmare. What we would ultimately have to  
express in this case is that we were wrong and not providing the  
behavior that anyone expects and that we had corrected it. Cumbersome  
instead of providing a default mechanism that does the right thing.  
In this case we're fortunate that it will bring far more benefit then  
harm. I think we've done the right thing in this case and the result  
will be users will be better off.

Jason.

>
> --
> Trygve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org