This page documents the procedure for making a new release branch.

Preparations

1. Execute the following command, in a checkout of master, substituting appropriate version numbers:

   git push origin master:releases/gcc-10
   

2. Update the file gcc/DEV-PHASE on the branch, to say "prerelease" instead of "experimental".
3. Update the file gcc/BASE-VER on the mainline, to use the next major release number (e.g., 11 instead of 10). Immediately after pushing that change, create the basepoint tag for the next release:

   git tag -a -m "GCC 11 basepoint" basepoints/gcc-11
   git push origin tag basepoints/gcc-11
   

4. Create a new htdocs/gcc-VERSION directory for the next major release in the wwwdocs repository and populate it with initial copies of changes.html and criteria.html.
5. Notify libstdc++ maintainers to update references to "mainline GCC" in libstdc++-v3/doc/xml/manual/status_cxx*.xml.

Web Site Updates

6. Add index.html and changes.html pages based on the previous release branch to the directory corresponding to the newly created release branch.
7. Update the toplevel index.html page to show the new active release branch, the current release series, and active development (mainline). Update the version and development stage for mainline.
8. Update the list of versions in the bugs.html page for 'Porting to'.

9. Update maintainer-scripts/crontab on the mainline by adding an entry to make snapshots of the new branch and adjusting the version number of the mainline snapshots. Run git pull in the gcc-checkout directory of the gccadmin account, and then actually install the updated crontab there.
   Generate the next mainline snapshot manually, using the -p option of the gcc_release script. For that single run, adjust the script such that the announcement mail is sent to you personally so that you can adjust references to the previous snapshot in the README and index.html files of the new snapshot as well as the mail itself before relaying it.
10. Regenerate gcc.pot and cpplib.pot. Send them to the translation project if no snapshot of this version was sent during development stage 3 or 4.

Bugzilla Updates

11. Create new versions in Bugzilla corresponding to the new mainline version. This can be accomplished by choosing "products", choosing "gcc", and editing the versions. Please do not delete old versions.
12. Create new target milestones in Bugzilla corresponding to the new mainline version. This can be accomplished by choosing "products", choosing "gcc", and editing the milestones. Please do not delete old target milestones.
13. Create new target milestones in Bugzilla for the second dot release on the branch. For example, when branching 3.4, create a milestone for 3.4.1 for PRs that can't be fixed in time for 3.4.0.
14. Bug regression summary needs to adjusted by maintainer-scripts/branch_changer.py with the following arguments:

    ./maintainer-scripts/branch_changer.py api_key --add=11:12
    

    The script adds '/12' to all PRs marked with a '[Regression x/y/z]' summary line. (Unless you add --doit, the script runs in dry mode only.)