Hi. The patch is about usage of new versioning scheme in examples.
Pushed, Martin --- htdocs/branch-closing.html | 8 ++++---- htdocs/releasing.html | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/htdocs/branch-closing.html b/htdocs/branch-closing.html index 80e81ecd..9e35acc1 100644 --- a/htdocs/branch-closing.html +++ b/htdocs/branch-closing.html @@ -31,10 +31,10 @@ actually install the updated crontab there.</li> <li><p>For every open bug whose summary contains the version number of the branch being closed and an indication that the bug is either specific to that version, or a regression in that version and possibly -later versions (for example, "[4.2/4.3 Regression]"), read the +later versions (for example, "[7/8 Regression]"), read the comments on that bug and determine what versions the bug is present in and what versions it is fixed in. (Some bugs whose summary contains -the version number may in fact be saying "GCC 4.2 has bug X" or +the version number may in fact be saying "GCC 7 has bug X" or similar when reporting a bug present in earlier and later versions as well; nothing need be done with such bugs after identifying that they are of that form.) Several things should be done for all regression @@ -43,7 +43,7 @@ and version-specific bugs for the branch being closed:</p> <ol> <li>Ensure that the version number of the branch at the time it is -closed (for example, "4.2.5" if the branch is being closed when that +closed (for example, "7.5" if the branch is being closed when that is the version number a compiler built from the branch would report) is listed in "Known to work" or "Known to fail" as applicable.</li> @@ -58,7 +58,7 @@ release branch on which it was fixed.</li> <li>If the bug is a regression that is not fixed on all subsequent release branches and on trunk then it needs to remain open. Remove the version number of the branch being closed from the summary (for -example, change "[4.2/4.3 Regression]" to "[4.3 Regression]". If the +example, change "[7/8 Regression]" to "[8 Regression]". If the milestone is not set, or is set to a version from the branch being closed, set it to the version number of the next release from the next oldest release branch.</li> diff --git a/htdocs/releasing.html b/htdocs/releasing.html index 48853f9c..c92f06bc 100644 --- a/htdocs/releasing.html +++ b/htdocs/releasing.html @@ -91,7 +91,7 @@ and add a link from the main <code>buildstat.html</code> page.</li> <li>Generate online documentation for the new release with <code>update_web_docs_git</code>. The appropriate command to run (as gccadmin) to generate the documentation would be <code>scripts/update_web_docs_git --r3.0.2 -dgcc-3.0.2</code> (with the current version +-r7.3.0 -dgcc-7.3.0</code> (with the current version number inserted). Link to it from <code>onlinedocs/index.html</code> (but don't break URLs to documentation for previous releases even if you remove the links to it). Create additionally @@ -137,8 +137,8 @@ versions.</li> <li>Create a new target milestone in Bugzilla corresponding to the dot release after the immediate next (for example create a milestone for -3.3.3 after releasing 3.3.1, so we can slip the milestone for PRs that -can't be fixed in time for 3.3.2). This can be accomplished by +7.3 after releasing 7.1, so we can slip the milestone for PRs that +can't be fixed in time for 7.2). This can be accomplished by choosing products, choosing gcc, and editing the target milestones. Please do <strong>not</strong> delete old target milestones.</li> -- 2.31.1
