On Fri, 16 Mar 2012, 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
> >
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
> >
> > 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?
The points are as follows
1) we want to make a release at some point
2) we want to give people a chance to test the release beforehand,
thus we do a release candidate - main testing focus is that
weird targets get built, to rule out show-stoppers
3) if we apply changes to a release candidate 2) is invalidated so
we'd need another release candidate - see point 1)
4) for 4.7.1 there will be a release candidate as well, thus 2)
is re-validated
so the issue is simply that when we have created a RC we don't want
_any_ changes. Ideally. Otherwise doing a release candidate is
pointless and we could just release without doing release candidates.
Richard.
