diff options
Diffstat (limited to 'binutils/README-how-to-make-a-release')
-rw-r--r-- | binutils/README-how-to-make-a-release | 120 |
1 files changed, 69 insertions, 51 deletions
diff --git a/binutils/README-how-to-make-a-release b/binutils/README-how-to-make-a-release index 574aa9d..7ab4c69 100644 --- a/binutils/README-how-to-make-a-release +++ b/binutils/README-how-to-make-a-release @@ -55,8 +55,8 @@ Approx time to complete from here: 2 hours ... 4. Create the release branch using: - git branch binutils-2_45-branch - git push origin binutils-2_45-branch + git branch binutils-2_46-branch + git push origin binutils-2_46-branch If you get a message like: @@ -66,7 +66,7 @@ Approx time to complete from here: 2 hours ... 5. Make sure that the branch is there. IE check out the branch sources: - git clone ssh://sourceware.org/git/binutils-gdb.git -b binutils-2_45-branch 2.45 + git clone ssh://sourceware.org/git/binutils-gdb.git -b binutils-2_46-branch 2.46 If you get a message about being in a "detached head" state, something has gone wrong... @@ -88,8 +88,8 @@ Approx time to complete from here: 2 hours ... ask Joel Brobecker <brobecker AT adacore DOT com>. 7. Rename the current HEAD version entry in Bugzilla, and create a - new one. E.g. rename "2.45 (HEAD)" to 2.45, and create - "2.46 (HEAD)": + new one. E.g. rename "2.46 (HEAD)" to 2.46, and create + "2.47 (HEAD)": https://sourceware.org/bugzilla/editversions.cgi?product=binutils @@ -97,18 +97,18 @@ Approx time to complete from here: 2 hours ... of the next release and the BRANCH to indicate that it is almost ready for the release. - So if the release is going to be 2.45 then the version number on - the BRANCH should be set to 2.44.90 - ie almost, but not quite 2.45, - and the version number on the MAINLINE should be set to 2.45.50 - - ie half way to 2.46 release. + So if the release is going to be 2.46 then the version number on + the BRANCH should be set to 2.45.90 - ie almost, but not quite 2.46, + and the version number on the MAINLINE should be set to 2.46.50 - + ie half way to 2.47 release. So the BRANCH bfd/version.m4 has: - m4_define([BFD_VERSION], [2.44.90]) + m4_define([BFD_VERSION], [2.45.90]) and the MAINLINE has: - m4_define([BFD_VERSION], [2.45.50]) + m4_define([BFD_VERSION], [2.46.50]) Regenerate various files on both branch and HEAD by configuring with "--enable-maintainer-mode --enable-gold --enable-shared" and then building @@ -136,17 +136,6 @@ Approx time to complete from here: 2 hours ... ./src-release.sh -x binutils - FIXME: Not sure if the following steps are needed... - - Add a .dirstamp file to the gas/doc subdirectory: - - touch -d `date +%Y-%m-%d` binutils-2.44.90/gas/doc/.dirstamp - tar rvf binutils-2.44.90.tar binutils-2.44.90/gas/doc/.dirstamp - rm binutils-2.44.90.tar.xz - xz -9 -k binutils-2.44.90.tar - - ...END OF FIXME - c. Build a test target using this tarball. cp binutils-*.tar.xz /dev/shm @@ -154,7 +143,12 @@ Approx time to complete from here: 2 hours ... tar xvf binutils-*.tar.xz mkdir build cd build + + For EVEN numbered releases: ../binutils-*/configure --quiet --enable-gold + For ODD numbered releases: + ../binutils-*/configure --quiet + make popd @@ -162,8 +156,8 @@ Approx time to complete from here: 2 hours ... d. Upload the pre-release snapshot to the sourceware FTP site: - scp binutils-2.44.90.tar.xz sourceware.org:/var/ftp/pub/binutils/snapshots - ssh sourceware.org sha256sum ~ftp/pub/binutils/snapshots/binutils-2.44.90.tar.xz + scp binutils-2.45.90.tar.xz sourceware.org:/var/ftp/pub/binutils/snapshots + ssh sourceware.org sha256sum ~ftp/pub/binutils/snapshots/binutils-2.45.90.tar.xz Paranoia: Compare the checksum with the local version. @@ -182,7 +176,7 @@ Dear Translation Project A snapshot of the branch sources can be found here: - https://sourceware.org/pub/binutils/snapshots/binutils-2.44.90.tar.xz + https://sourceware.org/pub/binutils/snapshots/binutils-2.45.90.tar.xz We hope to make the official release of the sources on the <DATE> although that could change if there are important bugs that need to @@ -217,6 +211,15 @@ Hi Everyone, Ideally I would like to make the release happen in two weeks time, i.e. <DATE>. Which I hope will be enough time for everyone to get their final fixes in. + +If this is an EVEN numbered release: + + Note - this release does contain the sources for GOLD. + +If this is an ODD numbered release: + + Note - this release does not contain the sources for GOLD. + ------------------------------------------------------------------------ 12. Build various different toolchains, test them and nag @@ -229,6 +232,10 @@ Hi Everyone, For the next few weeks, monitor the mailing list for new translations and respond to any requests to have patches applied to the branch. +Also - expect to receive lots of new/updated translations from the +Translation Project. These all need to be checked in to both the +mainline and the branch. + ============================================================================== ============================================================================== @@ -250,7 +257,7 @@ How to create the release. 21. a. Update the release number in bfd/version.m4 on the release branch to a whole new minor version number, without a point - value. Eg "2.44.90" becomes "2.45". NB/ Not: "2.45.00" + value. Eg "2.45.90" becomes "2.46". NB/ Not: "2.46.00" b. Change bfd/development.sh to set all values to "false". @@ -277,11 +284,10 @@ How to create the release. to exist in the master repository, and that the GDB project would need to agree to have it there. - e. Add ChangeLog entries for all of the updates and add a - "this-is-the-2.43-release" comment and commit. + e. Commit. git add . - git commit -m "This is the 2.45 release" + git commit -m "This is the 2.46 release" git push 22. Check that your file creation mask will create the @@ -308,17 +314,15 @@ How to create the release. If this is an EVEN numbered release: - ./src-release.sh -b -g -l -x -z binutils_with_gold + ./src-release.sh -b -g -l -x -z \ + -r `git log -1 --format=%cd --date=format:%F bfd/version.m4` \ + binutils_with_gold If this is an ODD numbered release: - ./src-release.sh -b -g -l -x -z binutils - - OR ... for a more reproducible tarball: - ./src-release.sh -b -g -l -x -z \ -r `git log -1 --format=%cd --date=format:%F bfd/version.m4` \ - [binutils | binutils_with_gold] + binutils 24. Check that the files in the tarballs have the correct permissions. @@ -327,7 +331,7 @@ How to create the release. Also check that the man files are not empty. (cf PR 28144). - tar tvf binutils-*.tar | grep -e "\.1" + tar tvf binutils-*.tar | grep -e "\.1" (look for zero sized files) 25. Sanity check the release on x86_64-pc-linux-gnu by building and running the testsuites (gas, gold, binutils and ld). @@ -349,7 +353,7 @@ How to create the release. make check-gas check-binutils check-ld make install-gas install-ld install-binutils install-gprofng - If this is an ODD numbered release: + If this is an EVEN numbered release: make -j1 all-gold make check-gold @@ -362,21 +366,23 @@ How to create the release. popd 26. Tag the branch with the new release number: - [optional: add "-u XXXXX" to sign with a gpg key] - enter a tag message such as: "Official GNU Binutils 2.4x release" + [Optional: add "-u XXXXX" to sign with a gpg key. + Note: This may require changing the setting of [gpg] in your .gitconfig file] + + Enter a tag message such as: "Official GNU Binutils 2.4x release" git tag -a <TAG> -u <Your Key> eg: - git tag -a binutils-2_44 -u DD9E3C4F <=== Be careful to get the tag right + git tag -a binutils-2_46 -u DD9E3C4F <=== Be careful to get the tag right or: - git tag -a binutils-2_44 -u DD9E3C4F -m "Official GNU Binutils 2.44 release" + git tag -a binutils-2_46 -u DD9E3C4F -m "Official GNU Binutils 2.46 release" NB/ If you do sign the binaries make sure to use a key that has been published with the FSF. Then push the release: - git push origin binutils-2_44 + git push origin binutils-2_46 If you get an error message along the lines of: "Invalid revision range ..." @@ -384,11 +390,11 @@ How to create the release. 27. Upload the tarballs to ftp.gnu.org. - gnupload --to ftp.gnu.org:binutils binutils-2.44.tar.* + gnupload --to ftp.gnu.org:binutils binutils-2.46.tar.* Be prepared to provide the password for the key, if you signed the binaries. - + The gnupload script is in the build-aux/ directory of the gnulib project's srouces. It uses the ncftp package for transmitting the files. @@ -417,8 +423,8 @@ How to create the release. Create a new docs sub-directory and move into it: cd binutils-htdocs - mkdir docs-2.45 - cd docs-2.45 + mkdir docs-2.46 + cd docs-2.46 Copy the index.html from the previous release @@ -454,8 +460,8 @@ How to create the release. cp <build-dir>/ld/ld.pdf . [NB/ Path not like others] [NB/ The gprofng documentation does not have a node-per-page selection] - cp <build-dir>/gprofng/doc/gprof.html . - cp <build-dir>/gprofng/doc/gprof.pdf . + cp <build-dir>/gprofng/gprof.html . + cp <build-dir>/gprofng/gprof.pdf . cp <build-dir>/libctf/doc/ctf-spec.html . cp <build-dir>/libctf/doc/ctf-spec.pdf . @@ -467,19 +473,20 @@ How to create the release. cd .. [Should now be in be in binutils-htdocs/ ] rm docs - ln -s docs-2.45 docs + ln -s docs-2.46 docs Edit index.html file to change the links to point to the new release, mention any new features, update dates and so on. - Check that the new web page is correct: + Check that the new web page is correct by opening it in a browser: file:///<path-to-binutils-htdocs>/index.html Add the new directories and files, commit and push the changes: + get add docs-2.46 git add . - git commit -m"Update documenation for the 2.45 release" + git commit -m"Update documenation for the 2.46 release" git push @@ -529,6 +536,17 @@ Cheers git log -1 --format=%cd --date=format:%F bfd/version.m4 +If this is an EVEN numbered release: + + As this is an even numbered release, the sources for the GOLD + linker are included. + +If this is an ODD numbered release: + + As this is an odd numbered release, the sources for the GOLD + linker are *not* included. + + This release contains numerous bug fixes, and also the following new features: |