All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaroslav Kysela <perex@perex.cz>
To: David Henningsson <david.henningsson@canonical.com>,
	ALSA development <alsa-devel@alsa-project.org>
Cc: Takashi Iwai <tiwai@suse.de>
Subject: Re: ALSA 1.0.28 release - request for testing
Date: Fri, 13 Jun 2014 19:17:37 +0200	[thread overview]
Message-ID: <539B3231.10105@perex.cz> (raw)
In-Reply-To: <539AD7F4.7070302@canonical.com>

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@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

  reply	other threads:[~2014-06-13 17:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-13  8:15 [RFC PATCH] alsactl: Do not run udev rule before datadir is mounted David Henningsson
2014-06-13  8:26 ` Jaroslav Kysela
2014-06-13  9:05   ` David Henningsson
2014-06-13  9:11     ` Jaroslav Kysela
2014-06-13  9:20     ` Takashi Iwai
2014-06-13  9:33       ` David Henningsson
2014-06-13 10:08         ` ALSA 1.0.28 release - request for testing Jaroslav Kysela
2014-06-13 10:52           ` David Henningsson
2014-06-13 17:17             ` Jaroslav Kysela [this message]
2014-06-13 10:59           ` Alexander E. Patrakov
2014-06-13 17:19             ` Jaroslav Kysela
2014-06-13 11:02           ` David Henningsson
2014-06-13 17:19             ` Jaroslav Kysela
2014-06-14 12:11           ` ALSA 1.0.28 release - Assertion failed Sergey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=539B3231.10105@perex.cz \
    --to=perex@perex.cz \
    --cc=alsa-devel@alsa-project.org \
    --cc=david.henningsson@canonical.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.