Re: [AD] Re: binary compatibility check

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-02-24, Chris <chris.kcat@xxxxxxxxxx> wrote:
> In Unix, I think this kind of thing is done with having a symlink called 
> libfoo.so.0 point to the latest library that'll work with programs that need 
> arbitrary-version-0 (eg. liballeg.so.0 -> liballeg-4.4.0.so). Allegro already 
> does something like this:

This symlink comes from the library's "soname", which is embedded in the
library.  This is set in makefile.ver.

> $ ll liballeg*
> -rwxr-xr-x  1 root root 840K Feb 17 16:07 liballeg-4.2.1.so
> lrwxrwxrwx  1 root root   17 Feb 21 13:31 liballeg.so.4.2 -> liballeg-4.2.1.so
> -rw-r--r--  1 root root 171K Feb 17 16:07 liballeg_unsharable.a
> 
> But it uses the actual library version, which means it implicitly breaks when 
> the major or minor version number changes, regardless if ABI was actually 
> broken.

That's because the Allegro 4.0 branch is defined as the branch which is
backwards- (and forwards-) compatible with the 4.0.0 release, and the
4.2 branch is the branch that is backwards-compatible with the 4.2.0
release.

> If the file's version number was independant of the library version 
> number, this implict break wouldn't occur. Instead, the name-enforced break 
> could be controlled by only changing the number when the devs saw fit (which 
> would be when backwards binary compatibility is broken).

(1) Backwards compatibility breakage used to only be allowed between a
stable branch and the next unstable branch, and

(2) Backwards compatibility breakage was implicitly assumed to _always_
occur between a stable branch and the next unstable branch.

Your proposal is the right way to do things (especially for commercial
libraries for which version numbers get bumped for non-technical
reasons), but we know for sure that 4.2 binaries won't work with
4.3/4.4, so if we adopt it we would only do it from 4.3 onwards.
And we would still not break backwards compatibility within a stable
branch.

Peter