X-Git-Url: http://drtracing.org/?a=blobdiff_plain;f=binutils%2FREADME-how-to-make-a-release;h=b9e7e946451bd79d3a8003877f67629221dcf2f2;hb=fe7d6a8db01f2a71520578267df7cd2d780ececb;hp=ab07e630372095be5f70b8d98a4aa1a1cbc4ff9d;hpb=4786fbf372d0d736884d25efe4fa69ee157315c7;p=deliverable%2Fbinutils-gdb.git diff --git a/binutils/README-how-to-make-a-release b/binutils/README-how-to-make-a-release index ab07e63037..b9e7e94645 100644 --- a/binutils/README-how-to-make-a-release +++ b/binutils/README-how-to-make-a-release @@ -39,8 +39,8 @@ How to perform a release. 4. Create the release branch using: - git branch binutils-2_33-branch - git push origin binutils-2_33-branch + git branch binutils-2_34-branch + git push origin binutils-2_34-branch If you get a message like: @@ -50,7 +50,7 @@ How to perform a release. 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_33-branch 2.33 + git clone ssh://sourceware.org/git/binutils-gdb.git -b binutils-2_34-branch 2.34 If you get a message about being in a "detached head" state, something has gone wrong... @@ -72,7 +72,7 @@ How to perform a release. ask Joel Brobecker . 7. Rename the current HEAD version entry in Bugzilla, and create a - new one. E.g. rename "2.33 (HEAD)" to 2.33, and create "2.34 + new one. E.g. rename "2.34 (HEAD)" to 2.34, and create "2.34 (HEAD)": https://sourceware.org/bugzilla/editversions.cgi?product=binutils @@ -80,13 +80,13 @@ How to perform a release. 8. Update bfd/version.m4 on HEAD to indicate that is now a snapshot of the next release: - m4_define([BFD_VERSION], [2.33.51]) + m4_define([BFD_VERSION], [2.34.50]) - Update the release number in bfd/version.m4 for the branch. + Update the release number in bfd/version.m4 for the BRANCH. The branch only needs the point value set to 90 as the release has not actually happened yet. - m4_define([BFD_VERSION], [2.32.90]) + m4_define([BFD_VERSION], [2.33.90]) Regenerate various files on both branch and HEAD by configuring with "--enable-maintainer-mode --enable-gold" and then building @@ -96,7 +96,7 @@ How to perform a release. Make sure that this includes the .pot files as well as the configure and makefiles. - 8. Create an initial pre-release: + 9. Create an initial pre-release: a. Remove any auto-generated files, in order to force the src-release script to rebuild them. @@ -110,12 +110,12 @@ How to perform a release. c. Build a test target using this tarball. - cp binutils-.tar.xz /dev/shm + cp binutils-.90.tar.xz /dev/shm cd /dev/shm - tar xvf binutils-.tar.xz + tar xvf binutils-.90.tar.xz mkdir build cd build - ..//configure --quiet --enable-gold + ../binutils-.90/configure --quiet --enable-gold make If there are problems, fix them. @@ -123,45 +123,45 @@ How to perform a release. d. Upload the pre-release snapshot to the sourceware FTP site: cd - scp binutils-.tar.xz sourceware.org:~ftp/pub/binutils/snapshots - ssh sourceware.org md5sum ~ftp/pub/binutils/snapshots/binutils-.tar.xz + scp binutils-.90.tar.xz sourceware.org:~ftp/pub/binutils/snapshots + ssh sourceware.org md5sum ~ftp/pub/binutils/snapshots/binutils-.90.tar.xz e. Clean up the source directory again. git clean -fdx . - 9. Tell the Translation Project where to find the new tarball. + 10. Tell the Translation Project where to find the new tarball. qv: http://translationproject.org/html/maintainers.html ------------------------------------------------------------------------ Dear Translation Project - The 2.3x release branch has been created for the FSF binutils. + The release branch has been created for the GNU binutils. A snapshot of the branch sources can be found here: - https://sourceware.org/pub/binutils/snapshots/binutils-2.3x.90.tar.xz + https://sourceware.org/pub/binutils/snapshots/binutils-.90.tar.xz - We hope to make the official release of the sources on the 8th July + We hope to make the official release of the sources on the although that could change if there are important bugs that need to be fixed before the release. ------------------------------------------------------------------------ - 10. Announce the availability of the snapshot and the branch on the + 11. Announce the availability of the snapshot and the branch on the binutils mailing list. Set a date for when the release will actually happen. Something like: ------------------------------------------------------------------------ Hi Everyone, - The 2.3x branch has now been created: + The branch has now been created: - git clone git://sourceware.org/git/binutils-gdb.git -b binutils-2_3x-branch 2.3x + git clone git://sourceware.org/git/binutils-gdb.git -b binutils--branch A snapshot of the sources is also available here: - https://sourceware.org/pub/binutils/snapshots/binutils-2.3x.90.tar.xz + https://sourceware.org/pub/binutils/snapshots/binutils-.90.tar.xz Please could all patches for the branch be run by me. The rules for the branch are: @@ -174,14 +174,15 @@ Hi Everyone, * Fixes for testsuite failures are OK. Ideally I would like to make the release happen in two weeks time, - i.e. Saturday 27th Jan. Which I hope will be enough time for everyone + i.e. . Which I hope will be enough time for everyone to get their final fixes in. ------------------------------------------------------------------------ - 11. Build various different toolchains, test them and nag + 12. Build various different toolchains, test them and nag maintainers to fix any testsuite failures for their architectures... +============================================================================== When the time comes to actually make the release.... @@ -195,7 +196,7 @@ When the time comes to actually make the release.... 21. 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.29.90" becomes "2.30". Change bfd/development.sh + value. Eg "2.34.90" becomes "2.35". Change bfd/development.sh to set all values to "false". Regenerate the configure and makefiles. And *info* files. Add ChangeLog entries for the updates and add a "this-is-the-2.3x-release" comment and @@ -210,7 +211,7 @@ When the time comes to actually make the release.... Remove any spurious autom4te.cache files left over from the reconfiguring: - % find . -depth -name autom4te.cache -exec rm -r {} \; + git clean -fdx 23. Note - check to see if any new files have been added to the top level of the source directory, but which are not in the @@ -222,22 +223,40 @@ When the time comes to actually make the release.... ./src-release.sh -b -g -l -x binutils 24. Check that the files in the tarballs have the correct - permissions. + permissions. (FIXME: How to do this ?) 25. Sanity check the release on x86_64-pc-linux-gnu by building and running the testsuites (gas, gold, binutils and ld). Make the source directory read-only before building. Also test "make install". If necessary fix any problems. + cd /dev/shm + mkdir delme + cd delme + tar xvf /binutils-2.X.tar.xz + chmod -R -w binutils-2.X + mkdir build + cd build + ../binutils-2.X/configure --enable-gold --prefix=`pwd`/install + make all-gas all-gold all-ld all-binutils all-gprof + make check-gas check-binutils check-ld check-gold + make install-gas install-gold install-ld install-binutils + 26. Tag the branch with the new release number: git tag -a binutils-2_3x [optional: add "-u XXXXX" to sign with a gpg key] - git push origin binutils-2_3x - + enter a tag message such as: "Official Binutils 2.3x 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_3x + + If you get an error message along the lines of "Invalid revision range ..." you can ignore it. + 27. Upload the tarballs to ftp.gnu.org. gnupload --to ftp.gnu.org:binutils binutils-2.3x.tar.* @@ -255,8 +274,9 @@ When the time comes to actually make the release.... chmod 644 binutils-2.3x.tar.* quit - FIXME: Should the signatures (created by the gnupload script in - step 29) be uploaded as well ? + FIXME: Are the signatures (created by the gnupload script in step 27) needed ? + [The above commands upload them and nobody has complained, so suggest that they + are retained]. 29. Update web pages. For sourceware.org: @@ -267,12 +287,19 @@ When the time comes to actually make the release.... cd /sourceware/www/sourceware/htdocs/binutils mkdir docs-2.3x cd docs-2.3x - mkdir as bfd binutils gprof ld + mkdir as + mkdir bfd + mkdir binutils + mkdir gprof + mkdir ld cd ../docs-2.3(x-1) get index.html Update the (local copy of the) index.html file to point to the new documentation and mention the new version and then upload it. + [NB/ FIXME: Special for updating from 2.34 documentation - restore + the link to the GAS/NEWS which has been changed for 2.34 to a + specific commit rather than the branch tag]. cd ../docs-2.3x put index.html @@ -284,7 +311,7 @@ When the time comes to actually make the release.... cd as lcd /gas/doc/as.html - put * + put * {be patient - this takes a long time...} cd ../bfd lcd ../../../bfd/doc/bfd.html put * @@ -299,7 +326,7 @@ When the time comes to actually make the release.... put * Edit the top level binutils index.html file to change the links - to the new documentation. + to point to the new documentation. cd ../../.. get index.html @@ -333,13 +360,13 @@ When the time comes to actually make the release.... checksums: xxxx - This release contains numerous bug fixes, and also the - following new features: + This release contains numerous bug fixes, and also the + following new features: - Our thanks go out to all of the binutils contributors, past and - present, for helping to make this release possible. + Our thanks go out to all of the binutils contributors, past and + present, for helping to make this release possible. ----------------------------------------------------------------------- @@ -357,13 +384,13 @@ When the time comes to actually make the release.... is now open for business as usual and that patched no longer need special approval. - 34. Examine the bfd/config.bfd file and move any pending obsolete - targets into the definitely obsolete section. Create a - changelog entry and commit. + 34. Examine the bfd/config.bfd file in the mainline sources and move + any pending obsolete targets into the definitely obsolete + section. Create a changelog entry and commit. -------------------------------------------------- +-------------------------------------------------------------------------- How to perform a point release. -------------------------------------------------- +-------------------------------------------------------------------------- A point release is easier than a normal release since a lot of the work has already been done. The branch has been created, the @@ -482,7 +509,7 @@ Hi Everyone, to "true". Commit this change. -Copyright (C) 2017-2019 Free Software Foundation, Inc. +Copyright (C) 2017-2020 Free Software Foundation, Inc. Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright