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       e. Add ChangeLog entries for all of the updates and add a
 254          "this-is-the-2.41-release" comment and commit.
 255
 256            git add .
 257            git commit
 258            git push
 259
 260   22. Check that your file creation mask will create the
 261       correct file permissions.  Eg:
 262
 263             % umask
 264             22
 265
 266       Remove any spurious autom4te.cache files left over from the
 267       reconfiguring:
 268
 269             git clean -fdx
 270
 271   23. Note - check to see if any new files have been added to the top
 272       level of the source directory, but which are not in the
 273       DEVO_SUPPORT variable in the src-release.sh script.  If they are
 274       needed then add them.
 275
 276       Create the release tarballs:
 277
 278             ./src-release.sh -b -g -l -x binutils
 279
 280       OR ... for a more reproducible tarball:
 281
 282             ./src-release.sh -b -g -l -x -r `git log -1 --format=%cd --date=format:%F bfd/version.m4` binutils
 283
 284   24. Check that the files in the tarballs have the correct
 285       permissions.
 286
 287            tar tvf binutils-*.tar.xz | grep -e "---"
 288
 289       Also check that the man files are not empty.  (cf PR 28144).
 290
 291            tar tvf binutils-*.tar.xz | grep -e "\.1"
 292
 293   25. Sanity check the release on x86_64-pc-linux-gnu by building and
 294        running the testsuites (gas, gold, binutils and ld).
 295       Make the source directory read-only before building.
 296       Also test 'make install'.
 297       Also build the html and pdf documentation files.
 298       If necessary fix any problems.
 299
 300         pushd /dev/shm
 301         mkdir delme
 302         cd delme
 303         tar xvf <path-to-sources>/binutils-2.*.tar.lz
 304         chmod -R -w binutils-2.*
 305         mkdir build
 306         cd build
 307         ../binutils-2.*/configure --quiet --enable-gold --prefix=`pwd`/install --enable-plugins --enable-shared
 308         make all-gas all-gold all-ld all-binutils all-gprof all-gprofng
 309         make check-gas check-binutils check-ld check-gold
 310         make install-gas install-gold install-ld install-binutils install-gprofng
 311
 312         # Needed for step 29...
 313         make html pdf html-libctf pdf-libctf html-libsframe pdf-libsframe
 314
 315         popd
 316
 317   26. Tag the branch with the new release number:
 318         [optional: add "-u XXXXX" to sign with a gpg key]
 319         enter a tag message such as: "Official GNU Binutils 2.4x release"
 320
 321             git tag -a binutils-2_41 -u DD9E3C4F      <=== Be careful to get the tag right
 322
 323         NB/ If you do sign the binaries make sure to use a key
 324         that has been published with the FSF.
 325
 326         Then push the release:
 327
 328             git push origin binutils-2_41
 329
 330         If you get an error message along the lines of:
 331           "Invalid revision range ..."
 332         you can ignore it.
 333
 334   27.  Upload the tarballs to ftp.gnu.org.
 335
 336           for A in bz2 gz lz xz ; do gnupload --to ftp.gnu.org:binutils binutils-2.41.tar.$A ; done
 337
 338         Be prepared to provide the password for the key, if you
 339         signed the binaries.
 340
 341         The gnupload script is in the gnulib/build-aux directory.
 342         It uses the ncftp package for transmitting the files.
 343
 344         Check for an email response from the upload.  If necessary
 345         fix any problems.  (The response might take a while, so
 346         proceed with the next steps if you are confident that
 347         everything is OK).
 348
 349   28. Upload the tarballs (and signatures) to sourceware.org:
 350
 351        sftp sourceware.org
 352          cd /sourceware/ftp/pub/binutils/releases
 353          put binutils-2.4*.tar.*
 354          chmod 644 binutils-2.4*.tar.*
 355          quit
 356
 357       FIXME: Are the signatures (created by the gnupload script in step 27)
 358       needed ?  [The above commands upload them and nobody has complained,
 359       so suggest that they are retained].
 360
 361   29. Update web pages.  For sourceware.org:
 362
 363       Create a new documentation folder on the sourceware.org web
 364       pages as /sourceware/www/sourceware/htdocs/binutils/docs-2.3x.
 365
 366        sftp sourceware.org
 367          cd /sourceware/www/sourceware/htdocs/binutils
 368          mkdir docs-2.4x
 369          cd docs-2.4x
 370          mkdir as
 371          mkdir bfd
 372          mkdir binutils
 373          mkdir gprof
 374          mkdir ld
 375          cd ../docs-2.3(x-1)
 376          get index.html
 377
 378       Update the (local copy of the) index.html file to point to the
 379       new documentation and mention the new version and then upload it.
 380
 381          cd ../docs-2.4x
 382          put index.html
 383
 384       Make the html documentation locally with the "make html" command.
 385       (This should have been done by step 25 above).
 386       Then upload and rename the directories as needed.
 387       (Sftp does not support recursive uploads however, so the directories
 388       have to be made and populated by hand).
 389
 390          cd as
 391          lcd <build-dir>/gas/doc/as
 392          put *                {be patient - this takes a long time...}
 393          lcd ..
 394          cd ..
 395          put as.html
 396          put as.pdf
 397
 398          cd bfd
 399          lcd ../../bfd/doc/bfd
 400          put *
 401          cd ..
 402          lcd ..
 403          put bfd.html
 404          put bfd.pdf
 405
 406          cd binutils
 407          lcd ../../binutils/binutils      <=== NB/ Path not like others
 408          put *
 409          cd ..
 410          lcd ../doc                       <=== Also not like the others
 411          put binutils.html
 412          put binutils.pdf
 413
 414          cd gprof
 415          lcd ../../gprof/doc/gprof
 416          put *
 417          cd ..
 418          lcd ../..                        <==== Different again
 419          put gprof.html
 420          put gprof.pdf
 421
 422          cd ld
 423          lcd ../ld/doc/ld
 424          put *
 425          cd ..
 426          lcd ../..
 427          put ld.html
 428          put ld.pdf
 429
 430          lcd ../gprofng/doc
 431          put gprofng.html
 432          put gprofng.pdf
 433
 434          lcd ../../libctf/doc
 435          put ctf-spec.html
 436          put ctf-spec.pdf
 437
 438          lcd ../../libsframe/doc
 439          put sframe-spec.html
 440          put sframe-spec.pdf
 441
 442       Edit the top level binutils index.html file to change the links
 443       to point to the new documentation.
 444
 445          cd ../..
 446          get index.html
 447          [edit]
 448          [check that it works]
 449          put index.html
 450          rm docs
 451          ln -s docs-2.4x docs
 452          quit
 453
 454       Check that the new web page is correct:
 455
 456           https://sourceware.org/binutils/
 457
 458       For the www.gnu.org site you have to email webmasters@gnu.org
 459       and ask them to copy the change(s):
 460 ---------------------------------------
 461 Hi FSF Webmasters,
 462
 463   Please could the GNU Binutils webpage at:
 464
 465 https://www.gnu.org/software/binutils/binutils.html
 466
 467   be updated to indicate that there is now a newer version available
 468   (2.3x).  I have already updated the related page on the sourceware
 469   website so this might be useful as a template:
 470
 471 https://sourceware.org/binutils/
 472
 473   Thanks very much.
 474
 475 Cheers
 476 --------------------------------------
 477
 478   30. Send emails to binutils@sourceware.org, info-gnu@gnu.org and
 479       David Edelsohn <dje.gcc@gmail.com> announcing the new release.
 480       Sign the email and include the checksum:
 481
 482           sha256sum binutils-2.4*.tar.*
 483
 484       (The email to Davis is so that he can update the GNU Toolchain
 485       social media).  Something like this:
 486       -----------------------------------------------------------------------
 487         Hi Everyone,
 488
 489         We are pleased to announce that version 2.4x of the GNU Binutils project
 490         sources have been released and are now available for download at:
 491
 492           https://ftp.gnu.org/gnu/binutils
 493           https://sourceware.org/pub/binutils/releases/
 494
 495           checksums: xxxx
 496
 497         As an experiment these tarballs were made with the new "-r <date>"
 498         option supported by the src-release.sh script.  This attempts to make
 499         reproducible tarballs by sorting the files and passing the
 500         "--mtime=<date>" option to tar.  The date used for these tarballs was
 501         obtained by running:
 502
 503           git log -1 --format=%cd --date=format:%F bfd/version.m4
 504
 505         This release contains numerous bug fixes, and also the
 506         following new features:
 507
 508           <extract info from the NEWS files>
 509
 510         For more information see:
 511
 512           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;;hb=refs/tags/binutils-2_4x
 513           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_4x
 514           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_4x
 515
 516         Our thanks go out to all of the binutils contributors, past and
 517         present, for helping to make this release possible.
 518
 519       -----------------------------------------------------------------------
 520
 521   31. Clean up the source tree:
 522
 523         git clean -fdx .
 524
 525   32. Edit bfd/development.sh on the branch and set the development flag
 526       to "true".  (Leave the experimental flag set to "false").  Also bump
 527       the version in bfd/version.m4 by adding a trailing .0, so that the
 528       date suffix keeps the version lower than the trunk version.
 529       Regenerate files.  Commit these changes.
 530
 531   33. Email the binutils list telling everyone that the 2.34 branch
 532       is now open for business as usual and that patches no longer
 533       need special approval.
 534
 535   34. Examine the bfd/config.bfd file in the mainline sources and move
 536       any pending obsolete targets into the definitely obsolete
 537       section.  Create a changelog entry and commit.
 538
 539
 540 --------------------------------------------------------------------------
 541 How to perform a POINT release.
 542 --------------------------------------------------------------------------
 543
 544 A point release is easier than a normal release since a lot of the
 545 work has already been done.  The branch has been created, the
 546 translations updated and the documentation uploaded.  So the procedure
 547 looks like this:
 548
 549   0. Decide that a point release is necessary.
 550
 551      Usually this only happens when a sufficient number of serious
 552      bugs have been found and fixed since the previous release, and a
 553      new official release is not imminent.
 554
 555   1. Tell the community that a point release is happening.  Ask
 556      maintainers to ensure that their ports are up to date on the
 557      release branch.  Ask the community if there are any bug fixes
 558      which are missing from the branch.  Allow some time for the
 559      responses to this step.
 560
 561   2. Make sure that the branch sources build, test and install
 562      correctly.
 563
 564   2.5 Prepare a list of the bugs which have been fixed.  This
 565       will be needed for step 8.
 566
 567   3. In the branch sources:
 568
 569        a. Update the minor release number in bfd/version.m4.
 570        b. Edit bfd/development.sh, set "development=false".
 571        c. Regenerate the configure files.
 572        d. Remove spurious autom4te.cache files:
 573
 574           git clean -fdx
 575
 576        e. Commit the updates along with a "this-is-the-2.3x.y-release"
 577           note in all of the changelogs.
 578        f. Tag the branch with the new release number:
 579
 580             git tag -a binutils-2_3x_y
 581               [optional: add "-u XXXXX" to sign with a gpg key]
 582             git push origin binutils-2_3x_y
 583
 584        g. Check that your file creation mask will create the
 585           correct file permissions.  Ie:
 586
 587             umask 022
 588
 589        h. Create the release tarballs:
 590
 591             ./src-release -b -g -l -x binutils
 592
 593        i. Check that the files in the tarballs have the correct
 594           permissions.
 595
 596        j. Clean the source tree again
 597
 598             git clean -fdx
 599
 600        k. Edit bfd/development.sh and set "development=true".
 601        l. Commit this change.
 602
 603   4. [If paranoid - upload the tarballs to one of the FTP servers and
 604       ask people to test it before going on to step 5].
 605
 606   5. Upload the tarballs to ftp.gnu.org.
 607
 608        gnupload --to ftp.gnu.org:binutils binutils-*.tar.*
 609
 610      The gnupload script is in the gnulib/build-aux directory.
 611
 612   6. Upload the tarballs to sourceware.org:
 613
 614        sftp sourceware.org
 615          cd /sourceware/ftp/pub/binutils/releases
 616          put binutils-*.tar.*
 617          chmod 644 binutils-*.tar.*
 618          quit
 619
 620     It is OK to upload the signatures as well.
 621
 622   7. Update web pages.  For sourceware.org:
 623
 624       * Log on to sourceware.org
 625       * Go to /sourceware/www/sourceware/htdocs/binutils
 626       * Edit index.html and update the latest release number (if this is a latest release)
 627
 628       For the www.gnu.org site you have to email webmasters@gnu.org
 629       and ask them to make the change(s).
 630
 631   8. Send an emails to the binutils list, info-gnu@gnu.org and
 632      David Edelsohn <dje.gcc@gmail.com> announcing the new release.
 633      (The email to Davis is so that he can update the GNU Toolchain
 634      social media).  Something like this:
 635
 636 ------------------------------------------------------------------------
 637 Hi Everyone,
 638
 639   We are pleased to announce that version 2.3x.y of the GNU Binutils
 640   project sources have been released and are now available for download at:
 641
 642     https://ftp.gnu.org/gnu/binutils
 643     https://sourceware.org/pub/binutils/releases/
 644
 645   This is a point release over the previous 2.3x version, containing bug
 646   fixes but no new features.
 647
 648   Our thanks go out to all of the binutils contributors, past and
 649   present, for helping to make this release possible.
 650
 651   Here is a list of the bugs that have been fixed:
 652     xx
 653     xx
 654     xx
 655     xx
 656 --------------------------------------------------------------------------
 657
 658   9. Create a new Bugzilla entry for the point release.
 659
 660        https://sourceware.org/bugzilla/editversions.cgi?product=binutils
 661
 662      And a new milestone too:
 663
 664        https://sourceware.org/bugzilla/editmilestones.cgi?product=binutils
 665 \f
 666 Copyright (C) 2017-2023 Free Software Foundation, Inc.
 667
 668 Copying and distribution of this file, with or without modification,
 669 are permitted in any medium without royalty provided the copyright
 670 notice and this notice are preserved.