Re: useless return values for apr_md5_*() functions...

On Sat, Apr 13, 2002 at 12:59:26AM +0200, Sander Striker wrote:
>...
> - The GA release of Apache _should_ not restrain APR from doing API changes.
> Sure, we can't go changing stuff at random to match which way the wind blows,
> but until APR goes 1.0 we should certainly be able to change the API IMO.

I'm hoping to find time to write up the versioning stuff that we hashed out
<whenever>, based on the apr_version.h header. Based on that information, we
will define a specific version and say that Apache httpd uses that version.
If we want to make changes to the API, then we will do so under the
constraints of the version numbering imposed by that system.

[ in short: X.Y.Z. changes in Z are backwards/forwards binary compatible;
  they are merely bug fixes, no API change at all. changes in Y introduce
  new APIs, possibly macros to map an old API into a new one once it gets
  compiled; binary compat is retained moving forward only (something linked
  against 2.1.x will work with 2.2.x, but not vice versa). changes in X
  require changes to be made in the application; deprecated APIs may be
  removed, signatures changed, etc. ]

> - Since the return values are always APR_SUCCESS for the md5 functions
> and it is _very_ unlikely that an implementation will need a return value,
> this is a valid change.

I think it is a lot further past "valid". See Karl's email for a *very*
lucid description of why this change should occur.

However, I think we can easily defer it until we have the rules fully
described for the APR Projects (plural). We'll introduce this API change
under those new rules.

So my answer for this particular patch is:

* -1 for now(*), pending introduction of the versioning

* add a ref to the patch to the STATUS file for tracking

* when versioning is doc'd and implemented, then we add it

* httpd must specify *WHICH* version of APR(UTIL) that it wants; it is not
  allowed to freeze the APR(UTIL) interfaces forever. Thus, it will say
  something like 1.x as a requirement. Based on the vsn rules, it will
  always be compat with that. at some point, it may need to say 1.x where
  x >= 2 if it starts using new APIs which get intro'd in APR 1.2.

Cheers,
-g

(*) in this case, -1 is a veto. I hate Bill's use of -1 as a vote. He should
    have used -0.5 to signify that he strongly dislikes it, but is not
    vetoing. It is insane to always have to qualify what -1 means because
    people change its definition.

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org