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