2.22.1 Possible -> Yes!

[Mike Frysinger]

On Friday 27 April 2012 10:33:23 H.J. Lu wrote:
> On Fri, Apr 27, 2012 at 7:28 AM, H.J. Lu wrote:
> > On Fri, Apr 27, 2012 at 7:26 AM, Mike Frysinger wrote:
> >> On Friday 27 April 2012 09:27:48 H.J. Lu wrote:
> >>> On Fri, Apr 27, 2012 at 3:37 AM, Alan Modra wrote:
> >>> > On Fri, Apr 27, 2012 at 12:07:15AM -0400, Mike Frysinger wrote:
> >>> >> Gentoo used to but found them too unstable.  so once the GNU
> >>> >> releases started picking up, we stopped relying on his snapshots.
> >>> > 
> >>> > HJ's snapshots are binutils trunk + some HJ patches.  One person
> >>> > decides when to release, and works on stabilising that release.  The
> >>> > entire binutils team ought to do better, don't you think?  Well, at
> >>> > least there's some chance we will!
> >>> 
> >>> If a binutuls can build kernel, gcc, glibc and binutils on x86, it is
> >>> good enough for me.  Any binutils release has bugs (some may be
> >>> critical), which may not be known if it isn't released.   I will make
> >>> sure that all bugs are fixed as soon as possible.  I don't see why it
> >>> should take a month to make a release.  A week should be plenty.  You
> >>> just deal with bugs.
> >> 
> >> yes, and the way you effectively deal with them is by branching and
> >> doing point releases.  constant releases from trunk won't help as there
> >> is always development going on there.
> > 
> > Just freeze trunk for a week to make a release and move on after
> > that.
> 
> We don't have to make each release from trunk as a major release.
> Trunk can be
> 
> 2.23
> 2.23.1
> 2.23.2.
> ..
> 
> At any time, we can call trunk 2.24.

yeah, i don't think that works.  it implies stability of patch choices which 
is not the case at all and goes against the versioning expectations of just 
about every other major project out there.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20120427/132064e9/attachment.sig>