Doing a release?

Emmanuel Deloget emmanuel.deloget at efixo.com
Thu Nov 7 11:55:49 UTC 2013


Hello Thomas and others,

On 06/11/2013 21:20, Thomas Petazzoni wrote:
> It's just that I think feature-based releases is a never-ending story.
> The current feature set hasn't moved too much for a while, so it would
> be good to make a release out of it, and as soon as 0.9.34-rc1 is out,
> re-open the tree to merge more features: stabilization of 0.9.34 and
> integration of additional features for 0.9.35 can take place in
> parallel.
>
> Thomas 

The fact is that feature-based releases for a libc is probably not the good
way to do it. The dependencies of a libc are:

* the OS kernel (Linux)
* the standards (C, POSIX...)

Linux stopped to make feature based released a while back - new features come
here and there so it's hard to justify that these new kernel features will be
the basis of a uCLibc feature-based release. *bsd releases are still feature-based
but then major releases are quite rare (not to mention that uCLibc does not
care much about *bds release cycles :) ).

The various standards on which uClibc is based does not evolve fast enough to
justify feature-based releases as well.

I would suggest to go the simplest route - a bi-annual release (with a 6 weeks
RC cycle where nothing but fixes are accepted). The uClibc development pace
does not justify a faster release cycle - and one release every 6 month is
quite good (this is roughly the time between 0.9.32 and 0.9.33). Integrator
would then have the assurance that a patch they propose, if accepted, would
go in the next release that would be out 6 month later in the worst case.

The fact that no uClibc has been released for the last 16 monthes is not
a good thing.

It might also be a good idea to list what might be the blocking points that
prevent a 1.0.0 release - having to cope with sub-1.0.0 release for such a
mature project seems weird. Of course, the bonus point of a calendar-based
release schedule is that you don't even have to assign version numbers to the
releases ("year.month" would do it).


Best regards,

-- Emmanuel Deloget

-------------- next part --------------
A non-text attachment was scrubbed...
Name: emmanuel_deloget.vcf
Type: text/x-vcard
Size: 268 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20131107/54564d6e/attachment.vcf>


More information about the uClibc mailing list