httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Date Tue, 23 May 2000 21:13:01 GMT

My original intent (I emphasize MY, because this is my opinion, not the
groups), was that APR should be treated like the C Run-time library.  We
always did everything we could to enforce binary backwards
compatability.  This seems difficult now.  So, my opinion has changed.  I
now believe that APR should ALWAYS been binary backwards compatible within
major releases, between major releases, we can break whatever we want.

Because this is open source, I would expect that we can release a new
major release whenever we break binary backwards compatability for APR
though, so this should be easy to accomplish.


On Tue, 23 May 2000, Jeff Trawick wrote:

> A few minutes ago, I said
> >                        I would be curious as to when you would want to
> > allow new functionality to be added which would extend ap_xlateattr_t
> > if the type is not opaque.  Would we have to wait for an APR version
> > number (major/minor/whatever) change?  I get nervous when I have to be
> > clairvoyant in order to maintain binary compatibility.
> This seems pretty silly in retrospect...  we don't have to do that, do
> we?
> At what point can we force apps to:
> 1) recompile if APR is dynamically loaded and they get a new copy (for
>    Apache's benefit) which has an updated interface
> 2) modify source code in order to still compile with a new APR 
> -- 
> Jeff Trawick | | PGP public key at web site:
>           Born in Roswell... married an alien...

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message