----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Saturday, February 09, 2002 9:46 PM Subject: Re: Speaking of deprecation...
> On Sat, 9 Feb 2002, Erik Hatcher wrote: > > > > I DON'T WANT TO UPGRADE THE BUILDFILE, and certainly not to be forced > > > to do that. > > > > So, don't upgrade your version of Ant then. > > But another project I depend on will. And probably another developer > will have the newer version of ant installed. > > I typically have at least 8 projects checked out at a time, > including 3 versions of tomcat, and I already have 2 versions > of ant installed. only two? I find that installs of tomcat like to sneak in an old drop of ant, which leads to some of the support calls we end up getting (user has ant1.4 installed, but is really running ant1.3 through a strange PATH setting) > > > > > > - you can write a makefile for a 10 year old make and it'll work with any > > > newer make. I don't have to upgrade my makefile with every release of gnu > > > make. > > > > Ant is NOT make. We should not necessarily make comparisons between the > > two. Getting rid of inconsistencies and cruft and keeping Ant's design and > > internals clean is a worthier goal than backwards compatibility in many > > respects. > > I'm not sure I understand you - ant and make are 2 tools that serve the > same purpose ( or at least you can use either of them to build a project). > I don't think there are too many things you can do in ant you can't do > in make. Ant started as a 'better' make. > > There are a lot of inconsistencies and cruft in make - yet all versions > of gnumake do their best to support all of those, and it seems all > those developers believe that respecting a defacto standard is more > important and worthier goal than making their design simpler. Here is a problem. Gnu Make may work across versions, but the programs that gnu calls have different stability guarantees. for a make to succeed, you need stability of (make,apps[1..n]); changes in compilers, linkers, underlying platforms can break make stability -you just dont blame make Because ant includes much of the implementation of the build stages, it has a harder time providing stability. Many of the changes between ant versions are not to the core itself, but to tasks -and many of those changes are to fix bugs. We are still getting ant 1.3 bugreps, 6 months after 1.4 shipped, and our universal response is 'upgrade'... We want people to upgrade as -we dont support old versions of ant -there is no financial reason not to upgrade -we think the newer versions are better :) I still unsure about how best to handle deprecation. On the one hand, I have just been tidying up attributes on the <zip> task family; on the other I dont want to force people to rework their build file when upgrading, as the new version should backwards compatible for build files unless we 'fix' something which really does change behaviour. Eriks property reworking is an example of that. What I am about to do to get failonerror workign with fork=false may be another. because of some underlying behaviour changes. I do think some time spent looking at 'what has changed' is important when upgrading. But should we force people to change attribute names because we have come up with better ones? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
