From dev-return-9660-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Apr 15 22:28:28 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 11282 invoked by uid 500); 15 Apr 2003 22:28:28 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 11269 invoked from network); 15 Apr 2003 22:28:28 -0000 Errors-To: Message-Id: <5.2.0.9.2.20030415171425.02099ec8@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 15 Apr 2003 17:22:22 -0500 To: Joe Orton From: "William A. Rowe, Jr." Subject: Re: HEAD and releases Cc: dev@apr.apache.org In-Reply-To: <20030415215859.GA2208@manyfish.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 04:58 PM 4/15/2003, Joe Orton wrote: >Has 0.9.3 actually been released? I see the tag, but can't find tarballs >for it. Is it just waiting for someone to make tarballs? Sure, drop 'em in! The more hands the merrier (offers /me who has had about 5 spare cycles/hour just for recharging batteries since 2.0.45 hit.) >Recently APR HEAD has been trying to keep backwards compatibility with >0.9.2, with the proviso that this will be dropped "for 1.0". It would >seem sensible to allow HEAD to drop this compatibility and move towards >"1.0" ASAP, so all these changes can start getting committed and tested. Sensible how? In that we prove we are unable to maintain source/binary compatibility, leading up to version 1.0 in which we establish our 'contract' with the users that the API won't change? >An APR "stable" branch will thus be needed which can be followed by the >httpd-2.0 stable branch; this could be called APR_0_9_BRANCH and forked >off the 0.9.3 tag. (future 0.9.x releases could be made from here too >if anyone felt inclined to make them) Silly. What future 0.9.x branch are you suggesting, 0.9.3.1.5? APR 1.0 will be 1.0 - and yes - when we feel ready to 'take the plunge' and enter into a permanant API contract for the lifespan of APR 1.0, then by all means we split off APR_0_9_BRANCH and go. In the meantime; there should really be absolutely zero change other than ripping the /* deprecated */ sections and flipping a couple of _ex() style APIs that were short term kludges. IOW, are we ready for 1.0? By my reading of STATUS, we aren't there yet. If we aren't, this discussion is premature, IMHO. I've always encouraged that we should start wrapping all /* @deprecated */ things in some sort of #ifndef APR_1_0_PROTOTYPE #endif and I would love to see us adopt that for very straightforward compatibility testing against older apps and modules. Bill