binutils/README-how-to-make-a-release

   1                 README for MAKING BINUTILS RELEASES
   2
   3 This is a collection of notes on how to perform a binutils release.  A
   4 lot of this information can also be found in the maintain.texi file in
   5 the gnulib project:
   6
   7   https://www.gnu.org/software/gnulib/
   8
   9 It is useful to have a cloned copy of the sources of this project as
  10 it also contains an upload script used to install tarballs on the GNU
  11 FTP server.
  12
  13 Make sure that you have upload authority on sourceware and fencepost.
  14 Beware - this is an involved process and can take weeks to complete.
  15 See the maintain.texi file for details on how to obtain these
  16 permissions.
  17
  18 -------------------------------------------------
  19 How to perform a release.
  20 -------------------------------------------------
  21
  22   1. Send an email out warning contributors about the forthcoming
  23      branch.  Set a date for the branch (weekends are better because
  24      they are less busy).
  25
  26   2. Update the libiberty and config directories and the top level
  27      configure files.
  28
  29   3. When branch day arrives add markers for the upcoming release to
  30      gas, ld, gold and binutils NEWS files.
  31        [If using the make-prerelease.sh script, check that
  32         common.sh has the right values].
  33        [make-prelease.sh command i]
  34        [make-prelease.sh command C]
  35      Likewise for all of the ChangeLog files.
  36      Add a note of the name of the new branch to binutils/BRANCHES.
  37      Commit these changes.
  38        [make-prerelease.sh command C]
  39
  40   4. Create the release branch using:
  41
  42         git tag -a binutils-2_30-branch   [eg for the 2.30 branch...]
  43         git push --tags origin binutils-2_30-branch
  44
  45   5. Update "BINUTILS_BRANCH" in gdbadmin's crontab:
  46
  47      Log in as gdbadmin on sourceware.org, and then:
  48
  49         $ cd crontab
  50         $ vi crontab
  51         [change BINUTILS_BRANCH]
  52         $ cvs ci crontab
  53         $ crontab crontab
  54
  55      If you do not have access to this account, please feel free to
  56      ask Joel Brobecker <brobecker AT adacore DOT com>.
  57
  58   6. Update bfd/configure and bfd/configure.ac on HEAD to indicate
  59      snapshot of the following release.
  60        [make-prerelease.sh command hv + C]
  61
  62   7. Rename the current HEAD version entry in Bugzilla, and create a
  63      new one.  E.g. rename "2.30 (HEAD)" to 2.30, and create "2.31
  64      (HEAD)".  Go to "Edit products" from the bottom toolbar, click on
  65      "binutils", then on "Edit versions".  If you don't have
  66      permissions to do this, either ask Daniel Berlin to fix your
  67      account or ask Daniel Jacobowitz to do it.
  68
  69   8. Regenerate various files on both branch and HEAD by configuring
  70      with --enable-maintainer-mode.  No need to check in changes to
  71      the autoconf/automake/etc files, but be sure the .pot files are
  72      up to date.  NB/ Remember to include gold and gprof.
  73
  74   9. Create an initial prerelease:
  75
  76      a. Change the version on the branch (bfd/version.m4), regenerate
  77         the files, and check this in.
  78
  79      b. Create a source tarball of the branch sources:
  80
  81            ./src-release -x binutils
  82
  83      c. Build a test target using this tarball.
  84
  85      d. Upload the prerelease snapshot to the FTP:
  86
  87           scp ../binutils-$version.tar.xz sourceware.org:~ftp/pub/binutils/snapshots
  88           ssh sourceware.org md5sum ~ftp/pub/binutils/snapshots/binutils-$version.tar.xz
  89
  90   10. Send it to the Translation Project:
  91
  92         http://translationproject.org/html/maintainers.html
  93
  94       Sending mail for one of the POT files is sufficient.
  95
  96   11. Announce the availability of the snapshot and the branch on the
  97       binutils mailing list.  Set a date for when the release will
  98       actually happen.  Nag maintainers to fix any testsuite failures
  99       for their architectures...
 100
 101 xxx -- fill in stuff here -- xxx
 102
 103 -------------------------------------------------
 104 How to perform a point release.
 105 -------------------------------------------------
 106
 107 A point release is easier than a normal release since a lot of the
 108 work has already been done.  The branch has been created, the
 109 translations updated and the documentation uploaded.  So the procedure
 110 looks like this:
 111
 112   0. Decide that a point release is necessary.
 113
 114      Usually this only happens when a sufficient number of serious
 115      bugs have been found and fixed since the previous release, and a
 116      new official release is not imminent.
 117
 118   1. Tell the community that a point release is happening.  Ask
 119      maintainers to ensure that their ports are up to date on the
 120      release branch.  Ask the community if there are any bug fixes
 121      which are missing from the branch.  Allow some time for the
 122      responses to this step.
 123
 124   2. Make sure that the branch sources build, test and install
 125      correctly.
 126
 127   2.5 Prepare a list of the bugs which have been fixed.  This
 128       will be needed for step 8.
 129
 130   3. In the branch sources:
 131
 132        a. Update the minor release number in bfd/version.m4.
 133        b. Edit bfd/development.sh and set "development=false".
 134        c. Regenerate the configure files.
 135        d. Commit the updates along with a "this-is-the-2.XX.X-release"
 136           note in all of the changelogs.
 137        e. Tag the branch with the new release number:
 138
 139             git tag -a binutils-2_XX_X
 140               [optional: add "-u XXXXX" to sign with a gpg key]
 141             git push origin binutils-2_XX_X
 142
 143        f. Check that your file creation mask will create the
 144           correct file permissions.  Eg:
 145
 146             umask 022
 147
 148        g. Create the release tarballs:
 149             ./src-release -b -g -l -x binutils
 150
 151        h. Check that the files in the tarballs have the correct
 152           permissions.
 153
 154        i. Edit bfd/development.sh and set "development=true".
 155        j. Commit this change into the git repository.
 156        k. Clean up the source tree.  (Use "git status" to find new
 157            files, and remove them).
 158
 159      FIXME: The tarballs will contain spurious autom4te.cache
 160      directories which could be removed to reduce their size.
 161
 162   4. [If paranoid - upload the tarballs to one of the FTP servers and
 163       ask people to test it before going on to step 5].
 164
 165   5. Upload the tarballs to ftp.gnu.org.
 166
 167        gnupload --to ftp.gnu.org:binutils binutils-X.XX.X.tar.*
 168
 169      The gnupload script is in the gnulib/build-aux directory.
 170
 171   6. Upload the tarballs to sourceware.org:
 172
 173        sftp sourceware.org
 174          cd /ftp/pub/binutils/releases
 175          put binutils-X.XX.X.tar.*
 176          chmod 644 binutils-X.XX.X.tar.*
 177          quit
 178
 179     FIXME: Should the signatures (created by the gnupload script in
 180     step 5) be uploaded as well ?
 181
 182   7. Update web pages.  For sourceware.org:
 183
 184       * Log on to sourceware.org
 185       * Go /www/htdocs/binutils
 186       * Edit index.html
 187
 188       For the www.gnu.org site you have to email webmasters@gnu.org
 189       and ask them to make the change(s).
 190
 191   8. Send an emails to the binutils list, info-gnu@gnu.org and
 192      David Edelsohn <dje.gcc@gmail.com> announcing the new release.
 193      (The email to Davis is so that he can update the GNU Toolchain
 194      social media).  Something like this:
 195 ------------------------------------------------------------------------
 196 Hi Everyone,
 197
 198   We are pleased to announce that version 2.XX.X of the Binutils project
 199   sources have been released and are now available for download at:
 200
 201     https://ftp.gnu.org/gnu/binutils
 202     https://sourceware.org/pub/binutils/releases/
 203
 204   This is a point release over the previous 2.XX version, containing bug
 205   fixes but no new features.
 206
 207   Our thanks go out to all of the binutils contributors, past and
 208   present, for helping to make this release possible.
 209
 210   Here is a list of the bugs that have been fixed:
 211     xx
 212     xx
 213     xx
 214     xx
 215 --------------------------------------------------------------------------
 216
 217 \f
 218 Copyright (C) 2017-2018 Free Software Foundation, Inc.
 219
 220 Copying and distribution of this file, with or without modification,
 221 are permitted in any medium without royalty provided the copyright
 222 notice and this notice are preserved.