Fabrizio Giustina wrote:
A big +1 for making it a default
I am also +1 on adding this to 2.0.6: for me this would just mean
removing tons of unneeded/workaround dependency from tons of poms. I
agree that, although consistent for some time, this behavior
introduces so much problems that should be considered a bug and not a
behavior.
Since anyway this is a important change and so many people are worried
about it, I would just propose to label 2.0.6 as 2.1 (trunk will
become 2.2). That should the reason for version numbers, right? We
shouldn't wait for trunk to be ready to name a release 2.1 and if we
introduce a change we should label it appropriately...
-1, because with this next release as 2.1, the 2.0 branch will no longer
be supported. What you're saying is basically 'we name the next release of
'2.0.x' '2.1''. What's the point of that? That's just the type of thing
that happens in commercial environments to satisfy PR and management.
So dropping 2.0.x and making 2.0.6 the next 2.1 is not an option.
Second option would be to keep 2.0.x in place and make 2.0.5 the starting
point of 2.1, with this patch in place. That would mean we still
have to support 2.0.x, and 2.1, which is no different from 2.0.x
except for MNG-1577, and the 2.1, what is now 2.1.
That's not an option either, since this little issue, although higly debated,
does not warrant a minor version update. yes, it changes behaviour. But fixing
a bug also changes behaviour.
Third option: keep 2.0.x buggy and only apply to 2.1.
Fourth option: apply to both 2.0.x and 2.1.
My vote goes to 4, after ofcourse we've tested a release candidate of 2.0.6.
-- Kenney
fabrizio
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> 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]
