On Tue, Jun 9, 2009 at 1:12 PM, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
Joe Orton wrote:
> On Tue, Jun 09, 2009 at 10:58:24AM -0500, William Rowe wrote:
>> Joe Orton wrote:
>>> On Tue, Jun 09, 2009 at 09:03:16AM -0500, William Rowe wrote:
>>>> As a packager, I can see how you might view 1.3.4-> as a minor version rev,
>>>> but from the perspective of any user deploying a package linked against
>>>> 1.3.4 and migrating to 1.3.7, no packages need to be recompiled.  That is
>>>> binary compatibility.
>>> This is a source compatibility issue though, just as it was when the
>>> LDAP buildfoo was broken in the same way.
>> No; the dbm and dbd are complete abstractions.
>
> You can't come along after the fact and draw compatibility lines
> wherever you please.

Then we freeze the code and correct no bugs, because every user exploiting
a bug is potentially the user of a feature.  DBM was abstracted by Greg and
Ryan to avoid *exactly* this problem, long before apr-1.0.0 shipped.

There is nothing in the autodocs suggesting that any dbm or dbd API are
valid apr_util calls.  That is as opposed to the incomplete ldap interface,
which we agree is bogus.

> APR-util has historically exported the DB library dependency.
> Applications depend on this.  It is part of the build API -- e.g.
> `apu-N-config --db-version` has no purpose otherwise.
>
> Breaking the exported dependency breaks source backwards compatibility.

Then vote for [one of] Bojan's patches.  I like the second one better,
having reviewed them both.  We'll undo this mess entirely in 2.0.

Bojan's patch restores the autogunk behavior to 1.3.8-dev quite effectively,
IMHO.  And I'm voting 0 because we disagree on this assessment, but I'm not
holding up improvements of compatibility if others believe that they are,
in fact, improvements.  The patch appears technically correct.

We didn't get any further than this on the db build compatibility issue, right?

(I don't see any commits or further discussion on this issue.)