On Jul 26 2016 17:43, Takashi Iwai wrote:
On Tue, 26 Jul 2016 09:07:43 +0200,
Takashi Sakamoto wrote:
Hi Jaroslav and Iwai-san,
On Jul 26 2016 15:57, Jaroslav Kysela wrote:
Dne 25.7.2016 v 11:58 Takashi Iwai napsal(a):
Hi Jaroslav,
shall we release v1.1.2 along with 4.7 kernel? We've got already a
bunch of changes in alsa-lib and co.
Hi,
yes, I plan to prepare the new release this week.
In this release, I added five APIs newly:
* snd_ctl_elem_info_set_dimension()
* snd_ctl_add_integer_elem_set()
* snd_ctl_add_integer64_elem_set()
* snd_ctl_add_boolean_elem_set()
* snd_ctl_add_enumerated_elem_set()
* snd_ctl_add_bytes_elem_set()
In this case, on usual way to maintain library, as long as I know,
minor version is going to be incremented, instead of micro version. In
short, to v1.2.0.
Good point. Although the minor/tiny version number rule is somewhat
ambiguous that people don't care much (as long as it's incremental),
it's still helpful to leave a number place for the further
corrections. We had to release a version like v1.0.21a in the past.
By releasing with the minor version bump, we may still release v1.2.1
soon after once if there is some build error or such a correction is
needed.
Yes. Of cource, we can have our own release policy, however following to
the usual way makes it easy for users or developers to get purpose of
the release.
But I committed assuming v1.1.2. For example:
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/control/control.c;h=6c00b8e50d2be78f9c5e93322b8e8b107ff8c442;hb=HEAD#l2533
If it's going to be versioned to v1.2.0, please tell it to me. I'll
post a patch to fix my commits in time of your release work.
They can be corrected easily here, too, hence no need to submit the
patch. It'd be a one-liner scripting, after all.
OK. Thanks.
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
