GCC Development Plan
(Suggestions for changes to this plan are discussed on the
GCC mailing list and approved or
rejected by the GCC Steering Committee.)
Objectives
The goals of this policy are:
- Higher-quality releases
- Support for more targets
- Continued encouragement of major infrastructure improvements
- More predictable release schedules
- More frequent releases
Rationale
It has been difficult for us to make consistent, high-quality
releases that support a wide variety of targets. In particular, GCC
3.0 achieved a high standard of quality on many targets, but was by no
means perfect, and failed to support as many targets as we would have
liked.
In addition, the release was late relative to original scheduling
estimates. And, the time between the GCC 2.95 and GCC 3.0 releases
was longer than everyone would have liked. We think that we will
better serve the user community by making releases somewhat more
frequently, and on a consistent schedule.
In addition, a consistent schedule will make it possible for the
Release Manager to better understand his or her time commitment will
be when he or she agrees to take the job.
Development Methodology
Branches
The development of major changes shall be done on a branch. (Under
some circumstances, development may be done in a private development
tree, but the Steering Committee strongly encourages the use of a
branch in the publicly accessible GCC development tree.)
Examples of major changes include:
- A new C++ parser
- A new memory allocation scheme for internal use in the compiler
- A new optimization pass
There is no firm guideline for what constitutes a "major change"
and what does not. If a developer is unsure, he or she should ask for
guidance on the GCC mailing lists. In general, a change that has the
potential to be extremely destabilizing should be done on a branch.
Changes may be merged from a development branch only after:
- They meet the standards for any other check-in. For example, the
code must be well-documented, and any user-visible changes, including
command-line options, should be documented in the manual.
- The branch has been validated on three different targets, each
targeting a different microprocessor family. Validation should
consist of bootstrapping the compiler (unless that is impossible for
the microprocessor selected) and checking that there are no new
regression test failures. It is acceptable to use a simulator for
validation; the use of real hardware is not required.
Rationale
Making major improvements to the compiler is good. However, such
changes are inevitably somewhat destabilizing. By using a branch, it
is possible for people to test and improve the code, but without
impacting other developers. By testing major changes more thoroughly
than ordinary changes, we will help reduce the impact on other
developers.
In addition, the presence of half-finished projects on the mainline
presents a variety of problems when preparing for a release. If
serious bugs remain, it may be impossible to do a release until the
bugs are fixed, thereby impacting the release schedule. If
functionality is present, but not robust (for example, command-line
options that activate an optimization pass that does not work very
well), then we can seriously confuse users.
Schedule
Development on our main branch will proceed in three stages. Each
stage will be two months in length.
During this period, changes of any nature may be made to the
compiler. In particular, major changes may be merged from branches.
In order to avoid chaos, the Release Manager will ask for a list of
major projects proposed for the coming release cycle before the start
of Stage 1. The Release Manager will attempt to sequence the projects
in such a way as to cause minimal disruption. The Release Manager
will not reject projects that will be ready for inclusion before the
end of Stage 1. Similarly, the Release Manager has no special power
to accept a particular patch or branch beyond what his or her status
as a maintainer affords. The Release Manager's role during Stage 1 is
merely to attempt to order the inclusion of major features in an
organized manner.
During this period, major changes may not be merged from branches.
However, other smaller improvements may be made. For example, support
for a new language construct might be added in a front-end, or support
for a new variant of an existing microprocessor might be added to a
back-end.
During this period, the only (non-documentation) changes that may be
made are changes that fix bugs or new ports which do not require changes
to other parts of the compiler.
New functionality may not be introduced during this period.
Rationale
In order to produce releases on a regular schedule, we must ensure
that the mainline is reasonably stable some time before we make the
release. Therefore, more radical changes must be made earlier in the
cycle, so that we have time to fix any problems that result.
In order to reach higher standards of quality, we must focus on
fixing bugs; by working exclusively on bug-fixing through Stage 3, we
will have a higher quality source base as we prepare for a release.
Although maintaining a development branch, including merging new
changes from the mainline, is somewhat burdensome, the absolute worst
case is that such a branch will have to be maintained for four months.
During two of those months, the only mainline changes will be bug-fixes,
so it is unlikely that many conflicts will occur.
Patch Reversion
If a patch is committed which introduces a regression on any target
which the Steering Committee considers to be important and if:
- the problem is reported to the original poster;
- 48 hours pass without the original poster or any other party
indicating that a fix will be forthcoming in the very near future;
- two people with write privileges to the affected area of the compiler
determine that the best course of action is to revert the patch;
then they may revert the patch.
(The list of important targets will be revised at the beginning of each
release cycle, if necessary, and is part of the release criteria.)
After the patch has been reverted, the poster may appeal the
decision to the Steering Committee.
Note that no distinction is made between patches which are
themselves buggy and patches that expose latent bugs elsewhere in
the compiler.
Rationale
If an important platform is broken, then it will be difficult to
prepare a release. If nobody volunteers to fix the problem, then we
will have an unpleasant choice: delay the release, or release a
compiler that we know to be worse than the previous release.
Therefore, it is important that we be able to revert patches that
cause problems. In addition, regressions on the mainline can impede
the development of other improvements.
On the other hand, we want to encourage new development, and new
development inevitably introduces new bugs. Therefore, it is
important that decisions be made on a case-by-case basis, and that the
proponent of a change have an opportunity to argue that the benefits
of the change outweigh the costs. Therefore, the decision to revert
requires two consenting parties, and such decisions may be appealed to
the Steering Committee. However, during the appeal, the mainline will
remain working, to avoid impeding other development.
Release Methodology
Schedule
At the conclusion of Stage 3, a release branch will be created.
On the release branch, the focus will be fixing any regressions
from the previous release, so that each release is better than the one
before.
The release will occur two months after the creation of the branch.
(Stage 1 of the next release cycle will occur in parallel.) If,
however, support for an important platform has regressed significantly
from the previous release or support for a platform with active
maintenance has regressed significantly relative to an earlier Stage
in the current release cycle, the release will be postponed until the
regressions are corrected, unless the Steering Committee releases the
automatic hold on the release.
Rationale
While making releases on schedule is important, quality should not
be subordinate to schedule. If a major platform is not adequately
supported, but was well supported in a previous release, then we
should address the problems. Presumably, this will not be unduly
difficult, since we will have spent four months fixing bugs by the
time the release would occur.
Bug-fix Releases
Bug-fix releases will be made two and four months after the initial
release, as necessary.
Rationale
By waiting for two months to make a bug-fix release, we will be
able to accumulate fixes for the most important problems, and avoid
spending undue amounts of time on release testing and packaging.
Here is a history of recent and a tentative timeline of upcoming
stages of development, branch points, and releases:
... former releases ...
|
+-- GCC 3.0 branch created ------+
| (Feb 12 2001) \
| v
v GCC 3.0 release (Jun 18 2001)
New development plan announced \
| (Jul 18 2001) v
| GCC 3.0.1 release (Aug 20 2001)
| \
v v
GCC 3.1 Stage 1 (ended Oct 15 2001) GCC 3.0.2 release (Oct 25 2001)
| \
v v
GCC 3.1 Stage 2 (ended Dec 19 2001) GCC 3.0.3 release (Dec 20 2001)
| \
v v
GCC 3.1 Stage 3 (ends Feb 15 2002) GCC 3.0.4 release (Feb 20 2002)
|
+-- GCC 3.1 branch created ------+
| \
| v
v GCC 3.1 release (May 15 2002)
GCC 3.2 Stage 1 (ends Jun 15 2002) \
| v
| GCC 3.1.1 release (Jul 25 2002)
| \
v v
New development plan announced Branch renamed to GCC 3.2 to
| (Jul 14 2002) accommodate for C++ ABI fixes
| (C++ binary incompatible with
| GCC 3.1, see release info)
| \
| v
| GCC 3.2 release (Aug 14 2002)
| \
| v
| GCC 3.2.1 release (Nov 19 2002)
| \
| v
| GCC 3.2.2 release (Feb 05 2003)
| \
| v
| GCC 3.2.3 release (April 22 2003)
v
GCC 3.3 Stage 2 (ends Aug 15 2002)
|
v
GCC 3.3 Stage 3 (ends Oct 15 2002)
|
+-- GCC 3.3 branch created ------+
| (Dec 14 2002) \
| v
| GCC 3.3 release (May 13 2003)
| \
v v
GCC 3.4 Stage 1 (ends July 4 2003) GCC 3.3.1 release (Aug 8 2003)
| \
v v
GCC 3.4 Stage 2 (ends October 15 2003) GCC 3.3.2 release (Oct 17 2003)
| \
v v
GCC 3.4 Stage 3 GCC 3.3.3 release (Feb 14 2004)
| \
| v
| GCC 3.3.4 release (May 31 2004)
| \
| v
| GCC 3.3.5 release (Sep 30 2004)
| \
| v
| GCC 3.3.6 release (May 03 2005)
|
+-- GCC 3.4 branch created ------+
| (Jan 16 2004) \
| v
Tree SSA infrastructure GCC 3.4.0 release (Apr 18 2004)
merged to mainline (May 17 2004) \
| v
v GCC 3.4.1 release (Jul 1 2004)
GCC 4.0 Stage 2 \
| v
v GCC 3.4.2 release (Sep 6 2004)
GCC 4.0 Stage 3 \
| v
| GCC 3.4.3 release (Nov 4 2004)
| \
| v
| GCC 3.4.4 release (May 18 2005)
| \
| v
| GCC 3.4.5 release (Nov 30 2005)
| \
| v
| GCC 3.4.6 release (Mar 06 2006)
|
+-- GCC 4.0 branch created ------+
| (Feb 25 2005) \
v v
GCC 4.1 Stage 1 (ends April 25 2005) GCC 4.0.0 release (Apr 20 2005)
| \
v v
GCC 4.1 Stage 2 (ends July 8 2005) GCC 4.0.1 release (Jul 7 2005)
| \
v v
GCC 4.1 Stage 3 GCC 4.0.2 release (Sep 28 2005)
| \
| v
| GCC 4.0.3 release (Mar 10 2006)
|
+-- GCC 4.1 branch created ------+
| (Nov 18 2005) \
v v
GCC 4.2 Stage 1 (ends Jan 18 2006) GCC 4.1.0 release (Feb 28 2006)
| \
v v
GCC 4.2 Stage 2 (ends Mar 18 2006) GCC 4.1.1 release (May 24 2006)
| \
v v
GCC 4.2 Stage 3 GCC 4.1.2 release
:
v
Please send FSF & GNU inquiries & questions to
gnu@gnu.org.
There are also other ways
to contact the FSF.
These pages are maintained by
the GCC team.
For questions related to the use of GCC, please consult these web
pages and the GCC manuals. If
that fails, the gcc-help@gcc.gnu.org
mailing list might help.
Please send comments on these web pages and the development of GCC to our
developer mailing list at gcc@gnu.org
or gcc@gcc.gnu.org. All of our lists
have public archives.
Copyright (C) Free Software Foundation, Inc.,
51 Franklin St, Fifth Floor, Boston, MA 02110, USA.
Verbatim copying and distribution of this entire article is
permitted in any medium, provided this notice is preserved.
|
Last modified 2006-06-21
|
|