Re: new "in-compatible" alsa-lib PCM API

[Takashi Iwai <tiwai@suse.de>]

At Tue, 17 Sep 2002 14:58:42 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> Hi all,
> 
> 	I've made a simple cleanup which unifies all snd_pcm_hw_params_* 
> functions. The first set of changes are in CVS a few days, but some 
> developers pointed that the backwards compatibility is a right thing.
> 	After some thoughs, I think that this sort of cleanups is good for 
> implementing at any time. It doesn't break the implementation (in the 
> sense of behaviour), but it makes that older code is not compilable. 
> Fortunately, any C programmer can fix the compilation in this case, so 
> it's definitely not a big problem.
> 	The much bigger drawback is that we have no binary compatibility 
> with older applications. I decided to use the versioned symbols in the 
> future versions of alsa library and to keep the binary compatibility with 
> older versions of library (function declarations). At the time, we have 
> two symbol versions: ALSA_0.9.0 and ALSA_0.9.0rc4.
> 	These solutions exists for co-existing older and newer 
> applications:
> 
> 1) New "versioned" library is libasound.so.3, so that older applications 
>    uses older libasound.so.2. 
> 2) Recompile older applications with "compatible library" which contains
>    versioned symbols ALSA_0.9, but headers are compatible with 0.9.0rc3. 
>    This library will be also libasound.so.3, but ALL symbols have ALSA_0.9 
>    tag which allows to override functions in future. The compatible library
>    will be built when '--with-compat-rc3' argument is passed to the 
>    configure script in alsa-lib. This solution allows keeping binary 
>    compatibility and allows to update alsa-lib with recent one (built 
>    without --with-compat-rc3).
> 
> I suggest to use the second solution from this time.

using the versioned symbols is a good idea.  it should go into
libasound.so.3 to avoid the further confliction.

but i still wonder whether it's possible not to modify the existing
api functions but to add new functions instead.
modifying the existing function means not only that the library
binares conflict but also that the application code must be changed,
too.  perhaps applications need to check the library version and bunch
of ifdef's or hacks, because many distribution includes still the old
alsa lib.

if we want to _force_ users to follow all the changes (e.g. the
function is really buggy, etc), then we should change the existing
function.
but in other cases - if the old api functions still work somehow -
adding new api functions makes our life happier.
we can put notes in the doc that the functions are obsolete.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab