On Fri, Apr 9, 2021 at 10:51 AM Martin Liška <mli...@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 >
