Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
