On Mon, 31 Oct 2011, Ian Lance Taylor wrote:
> No opinion on your actual question, but note that there is no more
> stage2. We now go directly from stage1 to stage3. This is just another
> feature of gcc development seemingly designed to confuse newbies, and
> evidently even confuses experienced developers.
So, let's fix this! In fact, this is something Mark, David and me
discussed at the last GCC Summit and which fell through the cracks
on my side.
Instead of renaming Stage 3 to Stage 2 at that point we figured that
using different terminology would reduce confusion. I am not wedded
to Stage A and B, though this seems to be the most straightforward
option (over colors, Alpha and Beta carrying a different meaning in
software development,...).
Thoughts?
Gerald
Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.127
diff -u -3 -p -r1.127 develop.html
--- develop.html 22 Mar 2012 07:57:04 -0000 1.127
+++ develop.html 10 Jun 2012 21:54:42 -0000
@@ -97,30 +97,27 @@ well), then we can seriously confuse use
<h3>Schedule</h3>
-<p>Development on our main branch will proceed in three stages.</p>
+<p>Development on our main branch will proceed as two main stages
+followed by concrete preparations for the release.</p>
-<h4><a name="stage1">Stage 1</a></h4>
+<h4><a name="stageA">Stage A</a></h4>
<p>During this period, changes of any nature may be made to the
compiler. In particular, major changes may be merged from branches.
-Stage 1 is feature driven and will last at least four months.
-In order to avoid chaos, the Release Managers will ask for a list of
+Stage A is feature driven and will last at least four months.</p>
+
+<p>In order to avoid chaos, the Release Managers will ask for a list of
major projects proposed for the coming release cycle before the start
of this stage. They will attempt to sequence the projects
in such a way as to cause minimal disruption. The Release Managers
will not reject projects that will be ready for inclusion before the
-end of Stage 1. Similarly, the Release Managers have no special
+end of this stage. Similarly, the Release Managers have no special
power to accept a particular patch or branch beyond what their status
as maintainers affords. The role of the Release Managers is merely
-to attempt to order the inclusion of major features in an organized
+to help order the inclusion of major features in an organized
manner.</p>
-<h4><a name="stage2">Stage 2</a></h4>
-
-<p>Stage 2 has been abandoned in favor of an extended feature driven
-Stage 1 since the development of GCC 4.4.</p>
-
-<h4><a name="stage3">Stage 3</a></h4>
+<h4><a name="stageB">Stage B</a></h4>
<p>During this two-month period, the only (non-documentation) changes
that may be made are changes that fix bugs or new ports which do not
@@ -196,7 +193,7 @@ remain working, to avoid impeding other
<h3>Schedule</h3>
-<p>At the conclusion of Stage 3, the trunk will go into release
+<p>At the conclusion of Stage B, the trunk will go into release
branch mode which allows documentation and regression fixes only.
During this phase, the focus will be fixing any regressions
from the previous release, so that each release is better than the one
@@ -204,7 +201,7 @@ before.</p>
<p>At the point the trunk is in a state suitable for releasing
a release branch will be created, a release candidate is made available
-and Stage 1 of the next release cycle starts.
+and Stage A of the next release cycle starts.
The decision on when this point is reached is up to the Release Managers.
In particular at this point no P1 regressions are present on the trunk.</p>
@@ -460,7 +457,7 @@ stages of development, branch points, an
+-- GCC 4.7 branch created ------+
| \
v v
- GCC 4.8 Stage 1 (starts 2012-03-02) GCC 4.7.0 release (2012-03-22)
+ GCC 4.8 Stage A (starts 2012-03-02) GCC 4.7.0 release (2012-03-22)
|
|
v
