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:
- 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 :-)
- 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