[alsa-devel] Packages 1.0.30 - release pending

[Liam Girdwood]

On Mon, 2015-10-12 at 10:24 +0200, Takashi Iwai wrote:
> On Sun, 11 Oct 2015 21:08:01 +0200,
> Jaroslav Kysela wrote:
> > 
> > Hi all,
> > 
> > 	I would like to release 1.0.30 version of all packages. Things to discuss:
> 
> There are pending issues: one is about the topology ABI and this seems
> still in flux.  I suppose this will be stabilized in 4.4.  Also, the
> documentation for BAT is utterly missing, and I expect we'll get this
> soonish.  Liam, Mengdong, any comments on these?

Han is now back from vacation today and is fixing all review comments
(including doing a man page). I'll be involved with grammar checking the
man page too as I'm the only native English speaker in the team.

Mengdong is back tomorrow and I think has a couple of topology patches
for the parser (to support the new ABI objects).

I think we can probably get both completed by Friday.

Thanks

Liam

> 
> We've discussed a bit about the user-space package release in the
> meeting.  Most people prefer more regular release.  My own preference
> is to stick with the kernel release cycle -- as most of features are
> related with the update of kernel ABI.  It's not necessarily at every
> kernel but, e.g. with two kernel releases, so that we'll get two or
> three releases per year.  It's just my $0.02, not insisting on it,
> though.
> 
> 
> > 1) tinycompress
> >    - do the release this library, too ?
> 
> Yeah, this was requested in the meething, too.
> 
> >    - versioning - follow the rule for all other ALSA packages
> >      (all packages have same version) ?
> 
> Vinod?
> 
> > 2) user-space versioning - change the numbering scheme ?
> > 
> > 	Basically, there aren't major rewrites of API last years and it won't
> > probably happen quickly. Some APIs might be redesigned - simplified
> > (mostly the mixer stuff), but I would propose to go from 1.0.x to 1.x
> > numbering (starting with 1.1) and when a major rewrite of API will be
> > included, we may change the first (major) version number. The release
> > frequency is not high, so it won't hurt anything in my eyes. Comments,
> > objections ? This discussion may end with 1.1 release instead 1.0.30.
> 
> Honestly speaking, not many people do care about the version number
> nowadays as long as it increases :)  But yes, I find your proposal
> good.  A minor update between regular release may still get a version
> number like 1.3.1, instead of the current 1.0.28a.
> 
> 
> thanks,
> 
> Takashi