ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: removing deprecated stuff
Date Sat, 24 Nov 2001 09:05:43 GMT
On Fri, 23 Nov 2001 20:09, Stephane Bailliez wrote:
> > If the XSLT file can be made safe enough then that may be an
> > option. But
> The file is committed as ant-update.xsl, so you can remove your -1 :-)

I hope your not claiming thats safe or even vaguely close to complete ?

> While I fully understand the reasons, there is a balance between doing
> nothing and removing for fun to give a contribution to the world entropy.

thats why we have Ant2.x - start with a clean slate and go from there. Ant2.x 
is where we acknowledge that there is 0 backwards compatability guarenteed.

> Your previous statement about the fact that people are still using a tomcat
> version of whatever and would like to upgrade to the latest and everything
> works fine is not a valid one to me for a simple reason. If they decide to
> upgrade in 10 years that does not mean we should not remove them within 10
> years... the human nature is lazy by essence so if something works and we
> are using 0.1% of its features there are not much reasons to upgrade except
> the fun of upgrading.

thats nice - I definetly disagree. I think maintaining backwards 
compatability in same major version is a good thing. We have fixed points 
where we break backwards compatability. ie

Ant1.x -> Ant2.x -> Ant3.x

> Additionaly the example of Exolab is not a valid one either since Stefan
> asked them to upgrade Ant (AdaptX task)... and as you can see in the user
> list there are many shops that use a recent version of Ant... and some are
> even in the CVS version apparently...

exolab is just an example - I suspect you could ask Sam/gump peeps to see the 
full range of ant versions used in the projects it manages. And remember that 
these projects represent a best case example (ie Sam regularly submits 
patches to the projects to get them building in line and the projects tend to 
be more uptodate "open" projects).

> Our chance is that the build file is XML therefore it should be piece of
> cake to transform a tag into another...right ? :-)

When someone does it and tests it then ask me again. I think you are 
going to find it is not as easy as you think it is. 

You could possible write an "ant structure"-like tool and run it on all the 
different code bases, record the differences. Then when you could build unit 
tests to test transforming from one release to another. If you generated 
enough XML fragments and tested each of the transforms thouroughly enough 
then I would be happy to remove the old stuff. Of course then our users would 
be required to download a xslt library.

The problem is that is no small amount of work ... in fact it is a MASSIVE 
undertaking. If you really want to do it then no one will stop you - but 
don't underestimate the amount of effort required to get it done right and 
tested. And it is also relatively boring work ;)



Murphy's law - "Anything that can go wrong, will." 
(Actually, this is Finagle's law, which in itself 
shows that Finagle was right.)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message