[ANNOUNCE] 0.9.32-rc1 released

Carmelo Amoroso carmelo73 at gmail.com
Mon Dec 27 10:29:49 UTC 2010


On 25/12/10 14:29, Ed W wrote:
> Hi
> 
>> Once we've done a full SUSv4 audit we could start thinking about something like a 1.0.0.
>> This release will be 0.9.32
> 
> I personally think you are artificially attached to keeping the version numbers low (ie in the opposite direction)?  Why
> not call that SUSv4 release version 2? (or 3?)
> 
> I do get that the numbering is completely arbitrary, but equally you could be seen as arguing completely the opposite
> direction?  I mean to programmers, what is wrong with a major release of functionality occurring between version 2.3.4.5
> and 2.3.4.6?  However, to less technical folks it's a good hint as to the progress of the project
> 
> On the other hand it's not entirely unreasonable to point out that "much" of the world tends to use an easily increasing
> first digit for major releases (which in a previous thread it was already agreed that nearly all uclibc releases are
> pretty much "major releases"?), a minor release second digit and a point release third digit.  Agreed it's completely
> arbitrary, but it does help keep a sense of perspective on progress to an outside observer?
> 
> Anyway, the whole point is it's completely arbitrary...  (But I do think a major addition such as nptl threads is worth
> of an increase in major version number? SUSv4 audit might also be?)
> 
> Cheers
> 
> Ed W
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 

Please guys,
let's work together to improve further uClibc, without spending so much in discussions regarding
the numbering policy, that is anyway a important part of the release strategy.

I agree with Bernhard's current strategy. I'd suggest to include the prelink stuff in 0.9.33, so we can create
a rc1 once prelink will start to get merged, and continue with SUSv4 audit.

So we will have 0.9.32 -> NPTL, 0.9.33 -> prelink, keeping invasive changes separated.

Cheers,
Carmelo




More information about the uClibc mailing list