On Fri, Apr 12, 2002 at 03:13:18PM -0500, Karl Fogel wrote:
> "Bill Stoddard" <bill@wstoddard.com> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 12 22:29:17 2002