Return-Path: Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 11902 invoked from network); 25 Feb 2001 12:38:24 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO betaversion.org) (216.15.97.206) by h31.sny.collab.net with SMTP; 25 Feb 2001 12:38:24 -0000 Received: from betaversion.org ([192.168.1.104]) by betaversion.org (8.9.3+Sun/8.9.3) with ESMTP id EAA20404 for ; Sun, 25 Feb 2001 04:42:20 -0800 (PST) Message-ID: <3A98FEEC.E74C13D0@betaversion.org> Date: Sun, 25 Feb 2001 04:47:40 -0800 From: Federico Barbieri X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Avalon Development Subject: Re: FW: avalon moved. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Sam Ruby wrote: > > Federico Barbieri wrote: > > > > > kewl - keep it coming. A lot of the duplicity stuff in Avalon though > > > is done to support backwards compatability in some form or another. > > > > > > > I know and that's the main pain! I don't want to repackage and > > rearchitect everything nicely and screw all code. But deprecation in > > this situation is such a pain! So we could go for a 4.0 proposal while > > tuning the 3.1x branch. > > There is no harm in removing interfaces that nobody uses. Helping people > convert, though patches, benefits everyone. > I just don't want to deprecate classes without a very clear picture of the whole 4.0. If you have a need today and you think of a solution, implement it and deprecate the old class you'll end up in a ever evolving/ never stable development process. So IMHO the best path is to freze as much as possible 3.1 specification brach, face all issues in a coherent way on the 4.0 proposal, where you have freedom of movement and you can work on solutions instead of patches.