Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 29952 invoked from network); 5 Jan 2005 17:06:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 5 Jan 2005 17:06:23 -0000 Received: (qmail 44931 invoked by uid 500); 5 Jan 2005 17:06:11 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 44625 invoked by uid 500); 5 Jan 2005 17:06:04 -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 44362 invoked by uid 99); 5 Jan 2005 17:05:59 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from relay02.pair.com (HELO relay02.pair.com) (209.68.5.16) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 05 Jan 2005 09:05:18 -0800 Received: (qmail 70420 invoked from network); 5 Jan 2005 17:04:36 -0000 Received: from unknown (HELO ?164.55.144.122?) (unknown) by unknown with SMTP; 5 Jan 2005 17:04:36 -0000 X-pair-Authenticated: 164.55.254.103 Message-ID: <41DC1E25.3050804@electricjellyfish.net> Date: Wed, 05 Jan 2005 12:04:37 -0500 From: Garrett Rooney User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Leggett CC: dev@apr.apache.org Subject: Re: LDAP changes in apr-util 1.0.x References: <51767.196.8.104.31.1104939739.squirrel@196.8.104.31> <41DC1438.3070808@electricjellyfish.net> <41DC1D31.8050105@sharp.fm> In-Reply-To: <41DC1D31.8050105@sharp.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Graham Leggett wrote: > Garrett Rooney wrote: > >> I don't see any reason we couldn't roll a release, although since some >> newish stuff (like the multicast code) has recently gone in we might >> want to consider not including that, so as to give the API more time >> to prove itself before we set it in stone. > > > If we delay, then we have the six release candidates of apr v1.0 all > over again :( As long as the API is sound the multicast stuff should be > fine in theory, bugfixes can go into a point release. I'm not talking about delaying, I'm talking about making the release but excluding the multicast APIs from it. Multicast can make it into 1.2.x, once the API has stabalized and been implemented on some more platforms. -garrett