ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: Backwards compatability?
Date Sat, 20 Jul 2002 16:27:11 GMT

> 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 files over 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 its task 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
View raw message