[alsa-devel] ALSA 1.0.28 release - request for testing

Jaroslav Kysela perex at perex.cz
Fri Jun 13 19:17:37 CEST 2014


Date 13.6.2014 12:52, David Henningsson wrote:
> 
> 
> On 2014-06-13 12:08, Jaroslav Kysela wrote:
>> Hello all,
>>
>>    ALSA 1.0.28 packages are available for testing at
>>
>> ftp://ftp.alsa-project.org/pub/testing/
>>
>>    Please, report any issues. I expect to announce the release on Monday.
> 
> Thanks!
> 
> I'm testing build of alsa-lib now and I have two questions:
> 
> 1) the final so version seems to be libasound.so.2.0.0 for both 1.0.27 
> and 1.0.28. I'm not sure how important it is, but shouldn't this be 
> increased to 2.0.1 or 2.1.0 to reflect code changes?

I think that we had some discussion about this and we use different
system to identify new libraries:

1) there is snd_asoundlib_version() function
2) the packaging system identifies the exact used library version
3) we use deprecated linker warning for obsolete symbols
4) only "current" libtool version number will be changed when
   the library is not backwards compatible, otherwise all symbols must
   be present and compatible

Basically, we haven't found the current:revision:age numbering useable
for our rules and as the libtool documentation states, it should not
reflect the release number at all.

Even if the age is increased, nobody will have/known a correlation
between the package release version and the library version. It means -
we would update a number for nothing in this case.

Eventually (contradicting to the paragraphs above) the age might reflect
the release number in form like:

1.0.28.3  ->  2:0:283

Future alsa-lib numbering:

2.33.5 -> 3:0:335 or 2:1:335 (if the library is backward compatible)

And this makes the question, if the version of packages should be
increased to 2.0.0 in next release to lower the last number :-)

> 2) This probably is not a new issue, but I was wondering about all the 
> extra files created in configure.ac, e g ctl_symbols_list.c. Are they 
> ever cleaned by some "clean", "maintainerclean" or similar rule?

Nobody has required this. Patches are welcome. I'm using the 'git
archive' to obtain the sources without these extra files for the
packaging purposes and 'make dist'.

				Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.


More information about the Alsa-devel mailing list