Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 61666 invoked from network); 24 Jan 2002 11:29:00 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 24 Jan 2002 11:29:00 -0000 Received: (qmail 10502 invoked by uid 97); 24 Jan 2002 11:29:09 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 10486 invoked by uid 97); 24 Jan 2002 11:29:09 -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 10475 invoked from network); 24 Jan 2002 11:29:08 -0000 Message-Id: <200201241030.g0OAUq810680@mail008.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Ant Developers List" Subject: Re: [VOTE] Ant2 codebase adoption process Date: Thu, 24 Jan 2002 19:40:46 +1100 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Thu, 24 Jan 2002 04:15, costinm@covalent.net wrote: > - internals, core, extensions, etc. That can and should evolve, but I > don't understand why it have to be a huge jump instead of a gradual > process, and why we are discussing whole core replacements instead of > individual features that could be voted and discussed one by one, and > added in the current ant. Mainly because many of the features require backwards incompatible changes which are unacceptable in a stable released project that is used as widely as ant is. It would be iresponsible of ant-dev to put users through this IMHO. With ant1.x there is a large effort not to break build files, this sometimes is inevitable (ie every addition of a new task could potentially cause conflicts) but we try to minimize the inconvenience. With ant2 there is much more freedom to experiment with things and users don't have to suffer through changes (some of which will inevitably be poor changes and thus need to be reverted). > At this point and with the current usage of ant, no 'perfect' design > can justify the pain associated with changing the build files and tasks. If it was just aesthetics then I would agree but the reason for Ant2 is not that - it is to be able to provide functionality people have been begging for for ages. -- Cheers, Pete Duct tape is like the force. It has a light side, and a dark side, and it binds the universe together ... -- Carl Zwanzig -- To unsubscribe, e-mail: For additional commands, e-mail: