Re: [AD] Re: binary compatibility check

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2006-02-23 at 18:39 -0800, Chris wrote:
> > 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.

Argh.

> 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.

Yeah. So my case above is only normal backwards compatibility - 4.4.1
library is backwards compatible to 4.4.0 compiled programs.

> 
> 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.

So basically, we shouldn't break binary compatibility on minor version
(like 4.4 -> 4.5) changes?

-- 
Elias Pschernig