public inbox for gcc-cvs-wwwdocs@sourceware.org help / color / mirror / Atom feed
From: Martin Liska <marxin@sourceware.org> To: gcc-cvs-wwwdocs@gcc.gnu.org Subject: gcc-wwwdocs branch master updated. cf2c734b45f269743a849c3ff6401ceb8ad17901 Date: Fri, 9 Apr 2021 08:47:28 +0000 (GMT) [thread overview] Message-ID: <20210409084728.F3C85385DC30@sourceware.org> (raw) This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gcc-wwwdocs". The branch, master has been updated via cf2c734b45f269743a849c3ff6401ceb8ad17901 (commit) from 73d93766c6ee6c532ce1133be86b7f84af2cf8db (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit cf2c734b45f269743a849c3ff6401ceb8ad17901 Author: Martin Liska <mliska@suse.cz> Date: Thu Apr 8 16:09:57 2021 +0200 Use new release version numbering scheme in instructions. 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> ----------------------------------------------------------------------- Summary of changes: htdocs/branch-closing.html | 8 ++++---- htdocs/releasing.html | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) hooks/post-receive -- gcc-wwwdocs
reply other threads:[~2021-04-09 8:47 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210409084728.F3C85385DC30@sourceware.org \ --to=marxin@sourceware.org \ --cc=gcc-cvs-wwwdocs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).