APR versioning (was: cvs commit: httpd-2.0/server/mpm/worker worker.c)

[Greg Stein <gs...@lyra.org>]

On Wed, May 29, 2002 at 08:40:55PM -0400, Cliff Woolley wrote:
> On 30 May 2002 striker@apache.org wrote:
> > striker     02/05/29 17:21:27
> >
> >   Modified:    server/mpm/beos beos.c
> >                server/mpm/experimental/leader leader.c
> >                server/mpm/experimental/threadpool threadpool.c
> >                server/mpm/netware mpm_netware.c
> >                server/mpm/prefork prefork.c
> >                server/mpm/worker worker.c
> >   Log:
> >   Catch up with the apr_allocator_set_owner -> apr_allocator_owner_set renames
> >   in APR.
> 
> This requires an MMN bump (which is fine with me, since we've already done
> one in 2.0.37-dev, and I'm starting to see little point in going back
> now).  If there are other renames of this sort, we should get them in all
> at once.
> 
> Is the APR versioning system in place yet?

The header and the code is in there, but we also need to integrate it into
the build process so that we generate versioned .so files (e.g. libapr.so.1)
The mechanism has been added to apr, but not apr-util (yet).

But the versioning doc states that we are not (strictly) bound to retain API
compatibility as long as we have not reached version 1.0. Currently, APR is
labelled as 0.9.0.

So APR(UTIL) is somewhere on the line of "free to change the API at will"
and "please don't mess up httpd releases". If we made a formal 1.0 release
of APR(UTIL), then we could start applying the versioning rules to it quite
strictly.

A separate decision is whether to carry the versioning scheme into httpd. At
this point, I'd say "no". Until we show that it is working well for APR and
company, we can/should just let httpd stick to its current versioning model.


As a true action item, I might suggest making an official 0.9 release of APR
and APRUTIL, to get the release procedures set up and oiled. I'd suggest
that we do the release with the caveat of API changes until 1.0 is released
(just as a fallback; I doubt we'd really make any, but if we *do*, we don't
have to worry about all the rules), then we apply the thumbscrews to its
API. Note that I'd also suggest calling it 0.9 so we don't give false
impressions of a "real" 1.0 release. We need more field testing before then
(specifically with things like: where do the includes go? do we have vsn
numbers on the .so files? etc)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/