This is the mail archive of the
mailing list for the GCC project.
[wwwdocs] Simplify releasing.html
- From: Gerald Pfeifer <gerald at pfeifer dot com>
- To: Mark Mitchell <mark at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 21 Oct 2007 01:34:48 +0200 (CEST)
- Subject: [wwwdocs] Simplify releasing.html
while making the other changes to releasing.html I noticed that we can
now remove several conditionals in these instructions, simplifying them.
Also, I propose to use version numbers of the form X.Y.Z in the
examples where we currently have X.Y which we do not use any longer.
RCS file: /cvs/gcc/wwwdocs/htdocs/releasing.html,v
retrieving revision 1.30
diff -u -3 -p -r1.30 releasing.html
--- releasing.html 12 Oct 2007 19:47:50 -0000 1.30
+++ releasing.html 20 Oct 2007 23:31:50 -0000
@@ -12,12 +12,10 @@
<li>Before rolling the release, update the release notes web pages and
ensure that they are all listed in <code>contrib/gennews</code>.
-If using an overall announcement page for
-successive minor releases, as with GCC 3.0, this should note the new
-release without removing information about any previous minor releases
-in that series, and the <code>features.html</code> page for that
-release series should have details added of the changes in each minor
+On the announcement page for that release series, note the new
+release without removing information about any previous minor releases.
+The <code>features.html</code> page for that release series should have
+details added of the changes in each minor release.</li>
<li>Warn developers to abstain from checking in any code on the
@@ -37,24 +35,19 @@ href="translation.html#regen">Regenerate
<code>maintainer-scripts/gcc_release</code> script from the same
branch as the release. You must pass the <code>-f</code> option, to
indicate a final release, the <code>-r</code> option (for example,
-<code>-r 3.1</code>), to give the release version, and, if diffs
+<code>-r 4.2.3</code>), to give the release version, and, if diffs
against a previous release are to be generated, the <code>-p</code>
option, whose argument must name the <code>.tar.gz</code> file for a
previous release, in a directory containing all the
<code>.tar.gz</code> files for that previous release (for example,
-<code>-p /some/where/gcc-3.1/gcc-3.1.tar.gz</code>, where there are
-also files such as <code>/some/where/gcc-3.1/gcc-core-3.1.tar.gz</code>).</li>
+<code>-p /some/where/gcc-4.2.2/gcc-4.2.2.tar.gz</code>, where there are
+also files such as <code>/some/where/gcc-4.2.2/gcc-core-4.2.2.tar.gz</code>).</li>
<li>Upload the release to ftp.gnu.org.</li>
-<li>If you are making a release of GCC 4.1 or later: Increment the version
-number in <code>gcc/BASE-VER</code>. Restore the word "prerelease"
-(without the quotation marks) to <code>gcc/DEV-PHASE</code>.
-Check these files in.<br />
-If you are making a release of GCC 4.0 or earlier: Increment the
-version number in <code>gcc/version.c</code>, and put back the date
-stamp and (prerelease) annotation. Increment the version number in
+<li>Increment the version number in <code>gcc/BASE-VER</code>. Restore
+the word "prerelease" (without the quotation marks) to
+<code>gcc/DEV-PHASE</code>. Check these files in.</li>
<li>Notify developers that checkins to the branch are once again