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