This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thursday 26 April 2012 23:41:01 Alan Modra wrote: > On Thu, Apr 26, 2012 at 10:07:27PM -0400, Mike Frysinger wrote: > > a release from trunk means 2.23, not another 2.22. > > What matters the number? you've missed my point (see below), but specifically speaking, yes, if you release from trunk, you should be incrementing the 22. > > i also don't think you can > > say that the trunk is that much better considering it hasn't been > > released and tested on distros for a variety of targets. > > I do claim that. I can claim that based on the number of bugs I know > have been fixed on trunk but not on the branch. I also know that > people use trunk binutils in production, and HJ releases binutils > effectively off trunk all the time, so it's not as if trunk is only > tested by developers. yes, and his last release (2.22.52.0.1) had a fairly trivial but critical bug -- trying to use the environ with --gc-sections lead to undefined references causing all Gentoo builds to segfault. that's on x86_64. > Even distros use trunk snapshots as their base > for binutils, eg. RHEL6.3 is based on binutils-2.20.51.0.2. Gentoo used to but found them too unstable. so once the GNU releases started picking up, we stopped relying on his snapshots. i also don't think Redhat is a good example considering they have a full time team working on making the releases actually stable, and this: 58 files changed, 19467 insertions(+), 7295 deletions(-), 67 modifications(!) granted, some of those are Fedora-specific or in-development patches, but that does not install confidence that the vanilla hjlu releases are ready for prime time. > > if trunk really truly was as well > > tested & stable as you say, then we wouldn't have releases which were > > badly broken for some targets. this isn't anything specific to the 2.22 > > branch point, just a reality of development -- bugs slip through. every > > release has its own set of issues. > > Long release cycles tend to break less used targets. I think my > suggestion will allow shorter release cycles, simply because the > release process will not impact developer time so much. i'm not against shortened releases. i disagree that point releases are a waste of time. Linux certainly has benefited from them. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |