This is the mail archive of the
mailing list for the GCC project.
Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: Richard Guenther <rguenther at suse dot de>, gcc at gcc dot gnu dot org
- Date: Fri, 16 Mar 2012 14:34:41 +0000
- Subject: Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
- References: <alpine.LNX.firstname.lastname@example.org> <4F6343F6.email@example.com>
On 16 March 2012 13:45, Georg-Johann Lay wrote:
> Richard Guenther schrieb:
>> GCC 4.7.0 Release Candidate available from gcc.gnu.org
>> A second release candidate for GCC 4.7.0 is available from
>> and shortly its mirrors. ?It has been generated from SVN revision 185376.
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux. ?Please test it and report any issues to bugzilla.
> Some days ago I learned that even if there are solutions to reported bugs,
> these solutions is already upstream to trunk and approved to be backported
> to 4.7.1, these bugfixes are prohibited for the 4.7.0 release.
> Can someone explain this "fix as few as possible bugs" rule to me?
> I don't want to question that precedure, I just want to understand it.
> If the reason is "not destabilize the release": What is the advantage of
> having exact the same destabilization at a later point, namely for the 4.7.1
> release in this specific case?
If the change goes in to the 4.7 branch as soon as 4.7.0 is released
then it will have weeks or months of testing before the 4.7.1 release.
If the branch is unstable just after a release then there is more
time for fixes and testing than if it's unstable just before a