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
<<attachment: emmanuel_deloget.vcf>>
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc