On Wed, Mar 12, 2008 at 09:25:49PM +0100, Xavier Hanin wrote:
> On Wed, Mar 12, 2008 at 8:52 PM, Jing Xue <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 12, 2008 at 06:13:16PM +0100, Xavier Hanin wrote:
> >  > On Wed, Mar 12, 2008 at 3:38 PM, Jing Xue <[EMAIL PROTECTED]> wrote:
> >  > > On Wed, Mar 12, 2008 at 09:02:50AM +0100, Gilles Scokart wrote:
> >  > >  > I think it is because the id is set first by ant, then by the 
> > settings task.
> >  > >  > I guess that this behavior may depend on the ant version.
> >  > >  >
> >  > >  > Gilles
> >  > >
> >  > >  I'm having this same problem after upgrading to beta 2. It can be 
> > fixed
> >  > >  by adding explicitly override="true" to where ivy:settings is called.
> >  > >
> >  > >  I wonder whether it would make sense to make that the default, for the
> >  > >  sake of backward compatibility.
> >  > Since settings is new in Ivy 2, I don't see backward compatibility
> >  > with alphas and betas as a strong argument.
> >
> >  Normally it isn't, but if you look at how many changes/features have
> >  been introduced and how many people have started using ivy between alpha
> >  1 and beta 2 (from this list's traffic), they might as well have been
> >  the 2.0 and 2.5 releases. 8-)
> I understand, and we try to maintain backward compatibility... to some
> extent. What about people who starts using Ivy with beta 2, and who
> could complain about a backward compatibility issue if we change this
> in next version? I agree it's very unlikely, but I guess most people
> using Ivy alphas or betas are able to fix some minor things like
> adding an attribute when upgrading version.

Sure, I guess it's more of a nuisance than a real issue.

> And when we'll fix the
> actual problem (false negatives), the number of user of alpha and beta
> version who will have to make a change for the next version will be
> rather small IMO. So I'd really prefer to stick with a default which
> forces people to know they are overriding a previous definition.
> 
> Does it make sense?

Yeah, I see where you are coming from. The rationale behind not letting
people unknowingly override does pose a strong argument.

Cheers.
-- 
Jing

> 
> Xavier
> 

Reply via email to