[wwwdocs,pushed] Use new release version numbering scheme in instructions.

Message ID 77635523-a4c6-a061-aa2c-cc1604ebc0d3@suse.cz
State New
Headers show
Series
  • [wwwdocs,pushed] Use new release version numbering scheme in instructions.
Related show

Commit Message

Martin Liška April 9, 2021, 8:46 a.m.
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(-)

-- 
2.31.1

Comments

Richard Biener via Gcc-patches April 9, 2021, 9:02 a.m. | #1
On Fri, Apr 9, 2021 at 10:51 AM Martin Liška <mliska@suse.cz> wrote:
>

> 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


bugzilla versions include the .0, so this should be "7.5.0", "7.5"
is not a valid bugzilla GCC version (it is a valid target milestone only)

>  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


which means this one is correct.

>  choosing products, choosing gcc, and editing the target milestones.

>  Please do <strong>not</strong> delete old target milestones.</li>

>

> --

> 2.31.1

>
Martin Liška April 9, 2021, 10:04 a.m. | #2
On 4/9/21 11:02 AM, Richard Biener wrote:
> bugzilla versions include the .0, so this should be "7.5.0", "7.5"

> is not a valid bugzilla GCC version (it is a valid target milestone only)


Ah, thanks for heads up. Fixed in current master.

Martin

Patch

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>