From dev-return-11891-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Jun 04 07:04:53 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 11346 invoked from network); 4 Jun 2004 07:04:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 4 Jun 2004 07:04:53 -0000 Received: (qmail 70623 invoked by uid 500); 4 Jun 2004 07:05:15 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 70515 invoked by uid 500); 4 Jun 2004 07:05:14 -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 70495 invoked by uid 99); 4 Jun 2004 07:05:14 -0000 Message-ID: <40C011F9.9010708@persistent.co.in> Date: Fri, 04 Jun 2004 11:38:57 +0530 From: Amit Athavale User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@apr.apache.org CC: Justin Erenkrantz , "William A. Rowe, Jr." Subject: Re: documented 1.0 showstoppers References: <011942D40D8451315BF46FC2@st-augustin.ics.uci.edu> <20040603192110.GD24305@lyra.org> <64763.69.17.22.137.1086301226.squirrel@www.jetnet.co.uk> <20040604011606.GC25324@lyra.org> <20040604012853.GA28062@scotch.ics.uci.edu> <6.1.0.6.2.20040603233825.06e40ec0@pop3.rowe-clan.net> <06D6124BF27E42390631B791@[10.0.1.137]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Justin Erenkrantz wrote: > --On Thursday, June 3, 2004 11:43 PM -0500 "William A. Rowe, Jr." > wrote: > >> What Ryan, Amit and I are asking for (and that most of the rest of the >> world who *doesn't* directly participate in apr/dev decisions) is that >> the API is right. > > > Again, I think there is confusion about the versioning rules: we can > add in a brand new locking API into 1.1 - we just can't remove the old > one until 2.0. So, I don't see the rationale for holding up 1.0 even > if locking is 'broken.' > People have lived with this 'broken' API forever - I don't see the > urgency. According to my "release / versioning" understanding (which need not to be same as that of apr), when a major release happen and especially your first one, everything has settled down (atleast major issues) and your stated functionality is working as expected. Again according to my understanding, major release has to be logical in a sense that all devs, users etc should be happy with the quality of the product. If you are lacking a functionality its OK, we will roll it in next release. My argument is that if we release 1.0 which is lacking in quality (no/broken/non-portable locking API), people will loose faith. > Most likely scenario, the old locking API is deprecated in 1.1 when > someone decides to get off their butt and 'fix' it. If someone > happens to provide fixes in, say, two weeks before 1.0 is frozen - all > the better, then we could rip out the 'broken API' for 1.0. > > And, if the locking change were drastic enough to warrant a major > binary-incompatible change, so be it: we issue 2.0. There's no reason > we have to be conservative with our version numbers. We've done > *that* for long enough. ;-) I don't know much about past but I don't see any harm if we are conservative to maintain quality in releases. Anyway if we are releasing according to timetable suggested by David, we need to put this issue somewhere in BOLD. (it will avoid unnecessary bugs for APR)