ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: Speaking of deprecation...
Date Sat, 09 Feb 2002 22:38:09 GMT

----- Original Message -----
From: <costinm@covalent.net>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message