apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Only ONE back-compat hole discovered.
Date Fri, 28 Jun 2002 14:22:31 GMT
At 07:18 AM 6/27/2002, Thom May wrote:
>* Justin Erenkrantz (jerenkrantz@apache.org) wrote :
> > On Thu, Jun 27, 2002 at 09:42:12AM +0200, Sander Striker wrote:
> > > The options on this are:
> > <snip, snip, snip>
> >
> > 5) Do nothing as APR isn't released yet.
> >
> > Personally, I don't care about backwards compatibility until
> > we hit 1.0 of APR.  However, the fact that so much of APR has
> > stayed the same probably means that we can jump to 1.0.
>
>hrrm. I'm a fairly strong -1 on bumping apr to 1.0 at this point -
>we need to get the API consistent and clean, otherwise we're
>stuck with it for far too long

I agree here.  There are just a few hiccups to work out yet.

WHEN we bump, all old/deprecated symbols and interfaces go kapoof.
That should happen when we are certain we aren't deprecating any others,
for no good reason other than "we can't name things to save our lives."

Sander's goof in not keeping the ordering of fields can't be remedied now.
But we can, at least, put wrappers around such things so that they can't
be hurt by casual coding against apr, such as our own apr-util bucket code.
That includes not using the struct alignment as a macro of the sizeof(),
but rather as a function that returns -this- versions' sizeof().

My objection to the apr_allocator issue isn't that it was borked before 1.0
went out.  My objection is that we may discover ourselves borking it again
post-1.0 which would be badness.  Clean opaque types prevent us from
repeating this mistake.

Bill



Mime
View raw message