Is this a "Release-Critical" bug fix?
If not, I think source- and binary-incompatible changes are highly inappropriate right now. A "release candidate" is supposed to *stabilize* the interface and implementation. Making an incompatible change between rc3 and rc4 looks like a big step backwards. If at all possible, let's postpone this cleanup until after ALSA 0.9.0 is released. Put the release in maintenance mode, then clean up these functions in the 1.0.0 development tree. That will also be a good time to increment the library version number. Jaroslav Kysela <[EMAIL PROTECTED]> writes: > 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. > > Objections/further discussion is welcome. Regards, -- Jack O'Quin Austin, Texas, USA http://www.stellajazz.com ------------------------------------------------------- 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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
