Justin Erenkrantz wrote:
--On Thursday, June 3, 2004 11:43 PM -0500 "William A. Rowe, Jr." <[EMAIL PROTECTED]> 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)
