apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amit Athavale <amit_athav...@persistent.co.in>
Subject Re: documented 1.0 showstoppers
Date Fri, 04 Jun 2004 06:08:57 GMT

Justin Erenkrantz wrote:

> --On Thursday, June 3, 2004 11:43 PM -0500 "William A. Rowe, Jr." 
> <wrowe@rowe-clan.net> 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)

View raw message