From Sat Apr 13 01:15:51 2002 Return-Path: Delivered-To: Received: (qmail 77914 invoked by uid 500); 13 Apr 2002 01:15:50 -0000 Mailing-List: contact; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list Received: (qmail 77903 invoked from network); 13 Apr 2002 01:15:50 -0000 X-Authentication-Warning: gstein set sender to using -f Date: Fri, 12 Apr 2002 18:16:15 -0700 From: Greg Stein To: APR Development List , Subject: Re: useless return values for apr_md5_*() functions... Message-ID: <> Mail-Followup-To: APR Development List , References: <01d401c1e262$a2468ed0$ba381b09@sashimi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from on Sat, Apr 13, 2002 at 12:59:26AM +0200 X-URL: X-Spam-Rating: 1.6.2 0/1000/N 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 , 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,