ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: Backwards compatability?
Date Sun, 21 Jul 2002 01:05:53 GMT
Can't there be tests written for antcall to pick this up?
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


costinm@covalent.net wrote on 07/21/2002 02:27:11 AM:

> 
> > For instance, the changes in property inheritance between projects
> when you do 
> > sucessive project calls has broken a HUGE number of my build files. 
Almost 
> > universally I have a set of controller build files that in turn call 
worker 
> > build files that may in turn call other build files.
> 
> It's very unfortunate those were not discovered _before_ releasing 1.5.
> 
> IMHO this is a bug. 
> 
> We should fix it ( i.e. reverse the inheritance rules to 1.4 ) and 
release
> a 1.5.1 that fixes this problem, it is serious enough.
> 
> I tested all my 1.4 build files before 1.5 release, and Gump does a lot
> of testing - but it seems this one didn't show up. 
> 
> Bugs happen, there is no way to avoid them.
> 
> > To be honest I am getting very sick of updating the same ant filesover 
and 
> > over. Each release I have had to go through and make a large number of 

> > changes to builds to get things going again. I don't consider myself 
stupid 
> > or unknowledgable wrt Ant and thus I don't think it is a user error 
that is 
> > causing these constant incompatabilities.
> 
> +1
> 
> Good thing that at least we don't have to rename attributes in the build
> files.
> 
> 
> > What I want to know is how we plan to fix it in the future. With 
> our current 
> > "system" I am not sure there is a clean or elegant method via 
> which we can do 
> > this. The only thing that I can think of is versioning the names of 
the 
> > tasks.
> 
> No, there isn't. Testing is the only way to find bugs and regressions. 
> Maybe we can improve things - like make gump run closer to what the
> project wants ( i.e. without full CLASSPATH, etc ).
> 
> I partially agree with 'versioning', but the main goal should be to
> preserve backward compatibility and use versioning only when there's
> no way to keep backward compat.
> 
> 
> > For instance we upgrade <antcall/> in an incompatible way then itstask 
name 
> > would become <antcall2/> etc. To avoid the pain of maintaining 
> separate tasks 
> > we could do something similar to the following in each task that 
changed...
> 
> Or we add a an attribute to antcall to triger the different rules - with
> default to the old behavior, I don't think we need antcall2 in this 
case.
> 
> But the real question is if the new behavior is indeed that much better 
> than the old one.
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
<mailto:ant-dev-help@jakarta.apache.org>
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message