Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 72906 invoked from network); 22 Jul 2002 01:30:32 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Jul 2002 01:30:32 -0000 Received: (qmail 4228 invoked by uid 97); 22 Jul 2002 01:30:53 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 4204 invoked by uid 97); 22 Jul 2002 01:30:52 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 4171 invoked by uid 98); 22 Jul 2002 01:30:52 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Sun, 21 Jul 2002 18:27:50 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Ant Developers List Subject: Re: Backwards compatability? In-Reply-To: <5.1.0.14.0.20020721132116.02896cd0@mail.callenish.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sun, 21 Jul 2002, Bruce Atherton wrote: > I think Peter's complaint about constantly revamping his build files nicely > illustrates why the incremental approach to change that you are advocating > is the wrong one here. I think we should make as many changes at once as we > can see are needed so that users aren't continually suffering compatibility > breaks. And what makes you think that after ant2 there will be no change and it'll be the perfect system ? I know absolutely _nothing_ in the computer world where this happened. In general when you make 'as many changes at once' it's is very likely some will be wrong and need to be changed later. > I'm confused by your last clause, though. If "the main goal should be to > preserve backward compatibility", then why would the situation arise that > "there's no way to keep backward compat"? The goal you have defined has cut > that option off, hasn't it? Are you saying that there ARE goals that are > more important than backwards compatibility? My mistake - what I meant is: "one of my main goals will be to preserve reasonable backward compatibility". There are many important goals - and I think most of them can be achieved without braking backward compat. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: