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