On Fri, Apr 12, 2002 at 03:13:18PM -0500, Karl Fogel wrote: > "Bill Stoddard" <[EMAIL PROTECTED]> writes: > > -1 (not a veto) > > > > With the release of a major application (Apache 2.0), the APR API should > > not change unless > > there is a compelling reason. This is not a compelling reason. > > Sure, it can wait, no problem. > > However, I can see how this situation might start to get painful for > APR developers, as more and more applications use APR. Apache 2.0 is > just one of N dependents; is there some reason Apache's release > process should affect the rate of APR development for everyone? > > If Apache needs a less turbulent APR during release, perhaps it would > make sense to branch APR, so Apache developers can control which > changes affect them during that period. The trunk could continue as > before. > > Thoughts?
My take is that there is no reason not to have a return code even if our current implementation always returns APR_SUCCESS. We often encounter problems in APIs because we need a return code when the prototype doesn't have it. It's easier to add a return code when the prototype has it already rather than add it when the prototype returns void. -- justin
