Re: [AD] Re: binary compatibility check

[Chris <chris.kcat@xxxxxxxxxx>]

On Thursday 23 February 2006 04:17, Elias Pschernig wrote:
> Is this really true for DLLs? I only ever got a program to refuse
> starting up because of a missing symbol under Unix, never under Windows
> (but I don't use Windows a lot, so that doesn't tell terribly much.)

AFAIK, it should. Someone on a Windows machine could test it, though.

> Well, 4.3, as an unstable branch, will have neither forward nor backward
> compatibility at all, no one ever suggested anything else, unless I'm
> confusing something now.

No, you're right. I meant 4.3/4.4 and on. :)

> For 4.4, things will be different again of course. From a developers
> view, I'd like also 4.4 to have no forward compatibility, but I can see
> the reason for wanting it. Assume, there's a binary linux distribution,
> and they have lots of games compiled against Allegro 4.4.0. Now Allegro
> 4.4.1 comes out. If there's forward compatibility, they can update the
> allegro-4.4 package to 4.4.1 the next day, since the 4.4.0 games will
> still work. Otherwise, they would need to make an allegro-4.4.1 package,
> make new packages of all games depending on the new allegro-4.4.1, and
> so on.. so in short, we need forwards compatibility.

I think you may have that backwards. If you install Allegro 4.4.0 then build a 
program against 4.4.0, then update to Allegro 4.4.1, the program should still 
work. As long as the library is equal to, or newer than, what the program 
expects, it should run. It's only if the library is older than what the 
program expects.

And if you have Allegro 4.4.0, then update a program where the update relies 
on 4.4.1, it should be the package manager's responsibility to update Allegro 
to 4.4.1 first.


After some thinking though, do we really need to break backwards compatibility 
after 4.4? Assuming we get all the necessary structs hidden, the only thing 
that'll break forwards binary compatibility would be new functions (we can't 
change/remove functions or else that'll break API, a no-no AFAIK). And since 
that's never a problem when using a new lib with an older program..

My proposal here is this. Once the new API is complete enough that all the old 
API stuff is in the wrapper and doesn't need to be exposed, change the 
library name that programs link with to something like liballeg0.so (or 
alleg0.dll for Windows). Then if something comes along and breaks backwards 
binary compatibility, you change the lib name to liballeg1.so (alleg1.dll). 
This will allow it so you can keep all the binary-incompatible versions 
together on the same system, without conflict, and without requiring an ABI 
breakage for each minor version number change. On Unix systems, you'd still 
have the allegro-config script to automatically pass -lalleg0 or -lalleg1 
when linking depending on the latest version installed, since they should 
still be API compatible, while windows will have the import lib named 
liballeg.a as always.