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 Note - when performing a release it is helpful to edit this document
  19 as you go, updating the example commands so that they are ready for
  20 the release that follows.
  21
  22 -------------------------------------------------
  23 How to perform a release.
  24 -------------------------------------------------
  25
  26   1. Choose dates for the branch and release.  Weekends are better
  27      because they are less busy.  It is typical to leave two weeks
  28      between creating the branch and creating the release.
  29
  30      Send an email out warning contributors about the forthcoming
  31      branch and release.
  32
  33   2. When the branch date is near:  Update the libiberty and config
  34      directories and the top level Makefile and configure files.  Also
  35      consider updating the toplevel libtool files.
  36
  37 Approx time to complete from here: 2 hours ....
  38
  39   2.5 If you have not built from the sources recently then now is the
  40       time to check that they still work...
  41
  42   3. When branch day arrives add markers for the upcoming release to
  43      the NEWS files in gas, ld, and binutils.  No need to update NEWS
  44      in the gold directory - it has its own release numbering.
  45
  46      Likewise for the ChangeLog files in: bfd, binutils, config, cpu,
  47      elfcpp, gas, gold, gprof, include, ld, libctf, opcodes and toplevel.
  48
  49      Add a note of the name of the new branch to binutils/BRANCHES.
  50
  51      Commit these changes.
  52
  53   4. Create the release branch using:
  54
  55         git branch binutils-2_41-branch
  56         git push origin binutils-2_41-branch
  57
  58      If you get a message like:
  59
  60        remote: fatal: Invalid revision range 0000000000000000000000000000000000000000..f974f26cb16cc6fe3946f163c787a05e713fb77b
  61
  62      It appears that this can be ignored...
  63
  64   5. Make sure that the branch is there.  IE check out the branch sources:
  65
  66         git clone ssh://sourceware.org/git/binutils-gdb.git -b binutils-2_41-branch 2.41
  67
  68      If you get a message about being in a "detached head" state, something
  69      has gone wrong...
  70
  71      Keep the checked out sources - they are going to be needed in future
  72      steps.
  73
  74   6. Update "BINUTILS_BRANCH" in gdbadmin's crontab:
  75
  76      Log in as gdbadmin on sourceware.org, and then:
  77
  78         $ cd crontab
  79         $ vi crontab
  80         [change BINUTILS_BRANCH]
  81         $ cvs ci crontab
  82         $ crontab crontab
  83
  84      If you do not have access to this account, please feel free to
  85      ask Joel Brobecker <brobecker AT adacore DOT com>.
  86
  87   7. Rename the current HEAD version entry in Bugzilla, and create a
  88      new one.  E.g. rename "2.41 (HEAD)" to 2.41, and create
  89      "2.42 (HEAD)":
  90
  91         https://sourceware.org/bugzilla/editversions.cgi?product=binutils
  92
  93   8. Update bfd/version.m4 on HEAD to indicate that is now a snapshot
  94      of the next release and the BRANCH to indicate that it is almost
  95      ready for the release.
  96
  97      So if the release is going to be 2.41 then the version number on
  98      the BRANCH should be set to 2.40.90 - ie almost, but not quite 2.41,
  99      and the version number on the MAINLINE should be set to 2.41.50 -
 100      ie half way to 2.42 release.
 101
 102      So the branch bfd/version.m4 has:
 103
 104        m4_define([BFD_VERSION], [2.40.90])
 105
 106      and the mainline has:
 107
 108        m4_define([BFD_VERSION], [2.41.50])
 109
 110      Regenerate various files on both branch and HEAD by configuring
 111      with "--enable-maintainer-mode --enable-gold --enable-shared" and then building
 112      with "make all-binutils all-gas all-gold all-gprof all-gprofng all-ld"
 113
 114      Add ChangeLog entries for the updated files.  Commit the changes.
 115      Make sure that this includes the .pot files as well as the
 116      configure and makefiles.
 117
 118   9. Create an initial pre-release:
 119
 120      a. Remove any auto-generated files, in order to force the
 121         src-release script to rebuild them.
 122
 123           cd <branch-sources>
 124           git clean -fdx
 125
 126      b. Create a source tarball of the BRANCH sources:
 127
 128           ./src-release.sh -x binutils
 129
 130         FIXME: Not sure if the following steps are needed...
 131
 132         Add a .dirstamp file to the gas/doc subdirectory:
 133
 134           touch -d <today's date> binutils-2.<release>/gas/doc/.dirstamp
 135           tar rvf binutils-<release>.tar binutils-<release>/gas/doc/.ditstamp
 136           rm binutils-<release>.tar.xz
 137           xz -9 binutils-<release>.tar
 138
 139           eg:
 140             touch -d 2023-06-01 binutils-2.40.90/gas/doc/.dirstamp
 141             tar rvf binutils-2.40.90.tar binutils-2.40.90/gas/doc/.ditstamp
 142             rm binutils-2.40.90.tar.xz
 143             xz -9 binutils-2.40.90.tar
 144
 145          ...END OF FIXME
 146
 147      c. Build a test target using this tarball.
 148
 149            cp binutils-2.40.90.tar.xz /dev/shm
 150            pushd /dev/shm
 151            tar xvf binutils-2.40.90.tar.xz
 152            mkdir build
 153            cd build
 154            ../binutils-2.40.90/configure --quiet --enable-gold
 155            make
 156            popd
 157
 158         If there are problems, fix them.
 159
 160      d. Upload the pre-release snapshot to the sourceware FTP site:
 161
 162           scp binutils-2.40.90.tar.xz sourceware.org:/var/ftp/pub/binutils/snapshots
 163           ssh sourceware.org sha256sum ~ftp/pub/binutils/snapshots/binutils-2.40.90.tar.xz
 164
 165      e. Clean up the source directory again.
 166
 167          git clean -fdx
 168
 169   10. Tell the Translation Project where to find the new tarball.
 170       <coordinator@translationproject.org>
 171       qv: https://translationproject.org/html/maintainers.html
 172
 173 ------------------------------------------------------------------------
 174 Dear Translation Project
 175
 176   The 2.40 release branch has been created for the GNU Binutils project.
 177
 178   A snapshot of the branch sources can be found here:
 179
 180     https://sourceware.org/pub/binutils/snapshots/binutils-2.39.90.tar.xz
 181
 182   We hope to make the official release of the sources on the <DATE>
 183   although that could change if there are important bugs that need to
 184   be fixed before the release.
 185 ------------------------------------------------------------------------
 186
 187   11. Announce the availability of the snapshot and the branch on the
 188       binutils mailing list.  Set a date for when the release will
 189       actually happen.  Something like:
 190
 191 ------------------------------------------------------------------------
 192 Hi Everyone,
 193
 194   The <NEW_VERSION> branch has now been created:
 195
 196      git clone git://sourceware.org/git/binutils-gdb.git -b binutils-<NEW_VERSION>-branch
 197
 198   A snapshot of the sources is also available here:
 199
 200     https://sourceware.org/pub/binutils/snapshots/binutils-<OLD_VERSION>.90.tar.xz
 201
 202   Please could all patches for the branch be run by me.
 203   The rules for the branch are:
 204
 205     * No new features.
 206     * Target specific bug fixes are OK.
 207     * Generic bug fixes are OK if they are important and widely tested.
 208     * Documentation updates/fixes are OK.
 209     * Translation updates are OK.
 210     * Fixes for testsuite failures are OK.
 211
 212   Ideally I would like to make the release happen in two weeks time,
 213   i.e. <DATE>.  Which I hope will be enough time for everyone
 214   to get their final fixes in.
 215 ------------------------------------------------------------------------
 216
 217   12. Build various different toolchains, test them and nag
 218       maintainers to fix any testsuite failures for their
 219       architectures...
 220
 221 ==============================================================================
 222
 223 When the time comes to actually make the release....
 224
 225
 226   20. Make sure that the branch sources still build, test and install
 227       correctly.  Make sure that the sources are clean, without any
 228       patch files (.reg .orig *~) left over.
 229
 230          cd <branch>
 231          git clean -fdx
 232
 233   21. a. Update the release number in bfd/version.m4 on the release
 234          branch to a whole new minor version number, without a point
 235          value.  Eg "2.40.90" becomes "2.41".  NB/ Not: "2.41.00"
 236
 237       b. Change bfd/development.sh to set all values to "false".
 238
 239       c. Regenerate the configure and makefiles.  And *info* files.
 240
 241             make all-gas all-ld all-binutils all-gprof all-gold all-gprofng all-libctf
 242             make info
 243
 244       d. Create a ChangeLog from the git refs for all of the commits
 245          from when changelog entries were no longer required:
 246
 247            gitlog-to-changelog --since=2021-07-03 > ChangeLog.git
 248            git add ChangeLog.git
 249
 250          The gitlog-to-changelog script is part of the sources
 251          of the "config" project.
 252
 253          Add an entry for ChangeLog.git to the src-release.sh script's
 254          DEVO_SUPPORT list, so that it is included in the release.
 255
 256          FIXME: it would be better if the ChangeLog.git file was permanently
 257          added to the src-release.sh script, but this mean that it would have
 258          to exist in the master repository, and that the GDB project would
 259          need to agree to have it there.
 260
 261       e. Add ChangeLog entries for all of the updates and add a
 262          "this-is-the-2.41-release" comment and commit.
 263
 264            git add .
 265            git commit
 266            git push
 267
 268   22. Check that your file creation mask will create the
 269       correct file permissions.  Eg:
 270
 271             % umask
 272             22
 273
 274       Remove any spurious autom4te.cache files left over from the
 275       reconfiguring:
 276
 277             git clean -fdx
 278
 279   23. Note - check to see if any new files have been added to the top
 280       level of the source directory, but which are not in the
 281       DEVO_SUPPORT variable in the src-release.sh script.  If they are
 282       needed then add them.
 283
 284       Create the release tarballs:
 285
 286             ./src-release.sh -b -g -l -x binutils
 287
 288       OR ... for a more reproducible tarball:
 289
 290             ./src-release.sh -b -g -l -x -r `git log -1 --format=%cd --date=format:%F bfd/version.m4` binutils
 291
 292   24. Check that the files in the tarballs have the correct
 293       permissions.
 294
 295            tar tvf binutils-*.tar.xz | grep -e "---"
 296
 297       Also check that the man files are not empty.  (cf PR 28144).
 298
 299            tar tvf binutils-*.tar.xz | grep -e "\.1"
 300
 301   25. Sanity check the release on x86_64-pc-linux-gnu by building and
 302        running the testsuites (gas, gold, binutils and ld).
 303       Make the source directory read-only before building.
 304       Also test 'make install'.
 305       Also build the html and pdf documentation files.
 306       If necessary fix any problems.
 307
 308         pushd /dev/shm
 309         mkdir delme
 310         cd delme
 311         tar xvf <path-to-sources>/binutils-2.*.tar.lz
 312         chmod -R -w binutils-2.*
 313         mkdir build
 314         cd build
 315         ../binutils-2.*/configure --quiet --enable-gold --prefix=`pwd`/install --enable-plugins --enable-shared
 316         make all-gas all-gold all-ld all-binutils all-gprof all-gprofng
 317         make check-gas check-binutils check-ld check-gold
 318         make install-gas install-gold install-ld install-binutils install-gprofng
 319
 320         # Needed for step 29...
 321         make html pdf html-libctf pdf-libctf html-libsframe pdf-libsframe
 322
 323         popd
 324
 325   26. Tag the branch with the new release number:
 326         [optional: add "-u XXXXX" to sign with a gpg key]
 327         enter a tag message such as: "Official GNU Binutils 2.4x release"
 328
 329             git tag -a binutils-2_41 -u DD9E3C4F      <=== Be careful to get the tag right
 330
 331         NB/ If you do sign the binaries make sure to use a key
 332         that has been published with the FSF.
 333
 334         Then push the release:
 335
 336             git push origin binutils-2_41
 337
 338         If you get an error message along the lines of:
 339           "Invalid revision range ..."
 340         you can ignore it.
 341
 342   27.  Upload the tarballs to ftp.gnu.org.
 343
 344           for A in bz2 gz lz xz ; do gnupload --to ftp.gnu.org:binutils binutils-2.41.tar.$A ; done
 345
 346         Be prepared to provide the password for the key, if you
 347         signed the binaries.
 348
 349         The gnupload script is in the gnulib/build-aux directory.
 350         It uses the ncftp package for transmitting the files.
 351
 352         Check for an email response from the upload.  If necessary
 353         fix any problems.  (The response might take a while, so
 354         proceed with the next steps if you are confident that
 355         everything is OK).
 356
 357   28. Upload the tarballs (and signatures) to sourceware.org:
 358
 359        sftp sourceware.org
 360          cd /sourceware/ftp/pub/binutils/releases
 361          put binutils-2.4*.tar.*
 362          chmod 644 binutils-2.4*.tar.*
 363          quit
 364
 365       FIXME: Are the signatures (created by the gnupload script in step 27)
 366       needed ?  [The above commands upload them and nobody has complained,
 367       so suggest that they are retained].
 368
 369   29. Update web pages.  For sourceware.org:
 370
 371       Create a new documentation folder on the sourceware.org web
 372       pages as /sourceware/www/sourceware/htdocs/binutils/docs-2.3x.
 373
 374        sftp sourceware.org
 375          cd /sourceware/www/sourceware/htdocs/binutils
 376          mkdir docs-2.4x
 377          cd docs-2.4x
 378          mkdir as
 379          mkdir bfd
 380          mkdir binutils
 381          mkdir gprof
 382          mkdir ld
 383          cd ../docs-2.3(x-1)
 384          get index.html
 385
 386       Update the (local copy of the) index.html file to point to the
 387       new documentation and mention the new version and then upload it.
 388
 389          cd ../docs-2.4x
 390          put index.html
 391
 392       Make the html documentation locally with the "make html" command.
 393       (This should have been done by step 25 above).
 394       Then upload and rename the directories as needed.
 395       (Sftp does not support recursive uploads however, so the directories
 396       have to be made and populated by hand).
 397
 398          cd as
 399          lcd <build-dir>/gas/doc/as
 400          put *                {be patient - this takes a long time...}
 401          lcd ..
 402          cd ..
 403          put as.html
 404          put as.pdf
 405
 406          cd bfd
 407          lcd ../../bfd/doc/bfd
 408          put *
 409          cd ..
 410          lcd ..
 411          put bfd.html
 412          put bfd.pdf
 413
 414          cd binutils
 415          lcd ../../binutils/binutils      <=== NB/ Path not like others
 416          put *
 417          cd ..
 418          lcd ../doc                       <=== Also not like the others
 419          put binutils.html
 420          put binutils.pdf
 421
 422          cd gprof
 423          lcd ../../gprof/doc/gprof
 424          put *
 425          cd ..
 426          lcd ../..                        <==== Different again
 427          put gprof.html
 428          put gprof.pdf
 429
 430          cd ld
 431          lcd ../ld/doc/ld
 432          put *
 433          cd ..
 434          lcd ../..
 435          put ld.html
 436          put ld.pdf
 437
 438          lcd ../gprofng/doc
 439          put gprofng.html
 440          put gprofng.pdf
 441
 442          lcd ../../libctf/doc
 443          put ctf-spec.html
 444          put ctf-spec.pdf
 445
 446          lcd ../../libsframe/doc
 447          put sframe-spec.html
 448          put sframe-spec.pdf
 449
 450       Edit the top level binutils index.html file to change the links
 451       to point to the new documentation.
 452
 453          cd ../..
 454          get index.html
 455          [edit]
 456          [check that it works]
 457          put index.html
 458          rm docs
 459          ln -s docs-2.4x docs
 460          quit
 461
 462       Check that the new web page is correct:
 463
 464           https://sourceware.org/binutils/
 465
 466       For the www.gnu.org site you have to email webmasters@gnu.org
 467       and ask them to copy the change(s):
 468 ---------------------------------------
 469 Hi FSF Webmasters,
 470
 471   Please could the GNU Binutils webpage at:
 472
 473 https://www.gnu.org/software/binutils/binutils.html
 474
 475   be updated to indicate that there is now a newer version available
 476   (2.3x).  I have already updated the related page on the sourceware
 477   website so this might be useful as a template:
 478
 479 https://sourceware.org/binutils/
 480
 481   Thanks very much.
 482
 483 Cheers
 484 --------------------------------------
 485
 486   30. Send emails to binutils@sourceware.org, info-gnu@gnu.org and
 487       David Edelsohn <dje.gcc@gmail.com> announcing the new release.
 488       Sign the email and include the checksum:
 489
 490           sha256sum binutils-2.4*.tar.*
 491
 492       (The email to Davis is so that he can update the GNU Toolchain
 493       social media).  Something like this:
 494       -----------------------------------------------------------------------
 495         Hi Everyone,
 496
 497         We are pleased to announce that version 2.4x of the GNU Binutils project
 498         sources have been released and are now available for download at:
 499
 500           https://ftp.gnu.org/gnu/binutils
 501           https://sourceware.org/pub/binutils/releases/
 502
 503           checksums: xxxx
 504
 505         As an experiment these tarballs were made with the new "-r <date>"
 506         option supported by the src-release.sh script.  This attempts to make
 507         reproducible tarballs by sorting the files and passing the
 508         "--mtime=<date>" option to tar.  The date used for these tarballs was
 509         obtained by running:
 510
 511           git log -1 --format=%cd --date=format:%F bfd/version.m4
 512
 513         This release contains numerous bug fixes, and also the
 514         following new features:
 515
 516           <extract info from the NEWS files>
 517
 518         For more information see:
 519
 520           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;;hb=refs/tags/binutils-2_4x
 521           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_4x
 522           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_4x
 523
 524         Our thanks go out to all of the binutils contributors, past and
 525         present, for helping to make this release possible.
 526
 527       -----------------------------------------------------------------------
 528
 529   31. Clean up the source tree:
 530
 531         git clean -fdx .
 532
 533   32. Edit bfd/development.sh on the branch and set the development flag
 534       to "true".  (Leave the experimental flag set to "false").  Also bump
 535       the version in bfd/version.m4 by adding a trailing .0, so that the
 536       date suffix keeps the version lower than the trunk version.
 537       Regenerate files.  Commit these changes.
 538
 539   33. Email the binutils list telling everyone that the 2.34 branch
 540       is now open for business as usual and that patches no longer
 541       need special approval.
 542
 543   34. Examine the bfd/config.bfd file in the mainline sources and move
 544       any pending obsolete targets into the definitely obsolete
 545       section.  Create a changelog entry and commit.
 546
 547
 548 --------------------------------------------------------------------------
 549 How to perform a POINT release.
 550 --------------------------------------------------------------------------
 551
 552 A point release is easier than a normal release since a lot of the
 553 work has already been done.  The branch has been created, the
 554 translations updated and the documentation uploaded.  So the procedure
 555 looks like this:
 556
 557   0. Decide that a point release is necessary.
 558
 559      Usually this only happens when a sufficient number of serious
 560      bugs have been found and fixed since the previous release, and a
 561      new official release is not imminent.
 562
 563   1. Tell the community that a point release is happening.  Ask
 564      maintainers to ensure that their ports are up to date on the
 565      release branch.  Ask the community if there are any bug fixes
 566      which are missing from the branch.  Allow some time for the
 567      responses to this step.
 568
 569   2. Make sure that the branch sources build, test and install
 570      correctly.
 571
 572   2.5 Prepare a list of the bugs which have been fixed.  This
 573       will be needed for step 8.
 574
 575   3. In the branch sources:
 576
 577        a. Update the minor release number in bfd/version.m4.
 578        b. Edit bfd/development.sh, set "development=false".
 579        c. Regenerate the configure files.
 580        d. Remove spurious autom4te.cache files:
 581
 582           git clean -fdx
 583
 584        e. Commit the updates along with a "this-is-the-2.3x.y-release"
 585           note in all of the changelogs.
 586        f. Tag the branch with the new release number:
 587
 588             git tag -a binutils-2_3x_y
 589               [optional: add "-u XXXXX" to sign with a gpg key]
 590             git push origin binutils-2_3x_y
 591
 592        g. Check that your file creation mask will create the
 593           correct file permissions.  Ie:
 594
 595             umask 022
 596
 597        h. Create the release tarballs:
 598
 599             ./src-release -b -g -l -x binutils
 600
 601        i. Check that the files in the tarballs have the correct
 602           permissions.
 603
 604        j. Clean the source tree again
 605
 606             git clean -fdx
 607
 608        k. Edit bfd/development.sh and set "development=true".
 609        l. Commit this change.
 610
 611   4. [If paranoid - upload the tarballs to one of the FTP servers and
 612       ask people to test it before going on to step 5].
 613
 614   5. Upload the tarballs to ftp.gnu.org.
 615
 616        gnupload --to ftp.gnu.org:binutils binutils-*.tar.*
 617
 618      The gnupload script is in the gnulib/build-aux directory.
 619
 620   6. Upload the tarballs to sourceware.org:
 621
 622        sftp sourceware.org
 623          cd /sourceware/ftp/pub/binutils/releases
 624          put binutils-*.tar.*
 625          chmod 644 binutils-*.tar.*
 626          quit
 627
 628     It is OK to upload the signatures as well.
 629
 630   7. Update web pages.  For sourceware.org:
 631
 632       * Log on to sourceware.org
 633       * Go to /sourceware/www/sourceware/htdocs/binutils
 634       * Edit index.html and update the latest release number (if this is a latest release)
 635
 636       For the www.gnu.org site you have to email webmasters@gnu.org
 637       and ask them to make the change(s).
 638
 639   8. Send an emails to the binutils list, info-gnu@gnu.org and
 640      David Edelsohn <dje.gcc@gmail.com> announcing the new release.
 641      (The email to Davis is so that he can update the GNU Toolchain
 642      social media).  Something like this:
 643
 644 ------------------------------------------------------------------------
 645 Hi Everyone,
 646
 647   We are pleased to announce that version 2.3x.y of the GNU Binutils
 648   project sources have been released and are now available for download at:
 649
 650     https://ftp.gnu.org/gnu/binutils
 651     https://sourceware.org/pub/binutils/releases/
 652
 653   This is a point release over the previous 2.3x version, containing bug
 654   fixes but no new features.
 655
 656   Our thanks go out to all of the binutils contributors, past and
 657   present, for helping to make this release possible.
 658
 659   Here is a list of the bugs that have been fixed:
 660     xx
 661     xx
 662     xx
 663     xx
 664 --------------------------------------------------------------------------
 665
 666   9. Create a new Bugzilla entry for the point release.
 667
 668        https://sourceware.org/bugzilla/editversions.cgi?product=binutils
 669
 670      And a new milestone too:
 671
 672        https://sourceware.org/bugzilla/editmilestones.cgi?product=binutils
 673 \f
 674 Copyright (C) 2017-2023 Free Software Foundation, Inc.
 675
 676 Copying and distribution of this file, with or without modification,
 677 are permitted in any medium without royalty provided the copyright
 678 notice and this notice are preserved.