Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 88597 invoked from network); 3 Dec 2001 20:15:15 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Dec 2001 20:15:15 -0000 Received: (qmail 5903 invoked by uid 97); 3 Dec 2001 20:15:19 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 5887 invoked by uid 97); 3 Dec 2001 20:15:19 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 5876 invoked from network); 3 Dec 2001 20:15:18 -0000 Message-Id: <200112032015.fB3KFGJ23172@mail004.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Avalon Developers List" Subject: Re: Moving Component Util Date: Tue, 4 Dec 2001 07:12:14 +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 Tue, 4 Dec 2001 06:35, Leo Sutic wrote: > > -----Original Message----- > > From: Peter Donald [mailto:peter@apache.org] > > > > More importantly it is meant to be stable and well tested. > > Yes, but it only needs to be so when it is actually released. Hope not. Every time some experimentzation gets done in Framework it almost invariably > While we are > still developing the next version the code will by necessity be unstable > and untested. Maybe you mean that with a release this close, no new code > should have been checked in? I think it should be checked into the proposal directories and then WHEN it is stable and it has achieved enough votes it can be moved to the main tree. Everytime someone starts messing with fundamental things and buggers it up my nightly builds go haywire. Backwards compatability was thrown to the wind when experimentation occured on COnfiguration stuff - enough that I just turned off my nightlies. WOuldn't it be better that backwards compatability had been kept, experimentation done in a branch, another tree and then merged across? Quite a bit of stuff gets added into Framework when it SHOULDN'T be. I was forced to back out changes at one stage because they had been -1'ed but not removed, framework breaks backwards compatability a few times - breaking some of my builds (interesting effect for a supposedly stable API), and recently it didn't even compile. None of these things should occur. > > I hope you are not suggesting this is good programming practice? > > It is. If you believe that then I guess we are going to have to agree to differ. -- Cheers, Pete --------------------------------------- Be nice to your friends. If it weren't for them, you'd be a complete stranger. --------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: