X-Git-Url: http://drtracing.org/?a=blobdiff_plain;f=binutils%2FREADME-how-to-make-a-release;h=38edac20ebf939ddf20dc162b0508499fde9331b;hb=bd756351a6d3dcff9915c88c26dc0a5811907f90;hp=47af677a9e3d834dac87ae63836197ef213ace93;hpb=eca4b721468e239a6a1ca7c9bd9c967085067dfe;p=deliverable%2Fbinutils-gdb.git diff --git a/binutils/README-how-to-make-a-release b/binutils/README-how-to-make-a-release index 47af677a9e..38edac20eb 100644 --- a/binutils/README-how-to-make-a-release +++ b/binutils/README-how-to-make-a-release @@ -27,27 +27,36 @@ How to perform a release. directories and the top level configure files. 3. When branch day arrives add markers for the upcoming release to - gas, ld, gold and binutils NEWS files. - [If using the make-prerelease.sh script, check that - common.sh has the right values]. - [make-prelease.sh command i] - Likewise for all of the ChangeLog files. + the NEWS files in gas, ld, gold and binutils. + + Likewise for the ChangeLog files in: bfd, binutils, config, cpu, + elfcpp, gas, gold, gprof, include, ld, opcodes and toplevel. + Add a note of the name of the new branch to binutils/BRANCHES. + Commit these changes. - [make-prerelease.sh command C] 4. Create the release branch using: - git branch binutils-2_31-branch - git push origin binutils-2_31-branch + git branch binutils-2_33-branch + git push origin binutils-2_33-branch + + If you get a message like: + + remote: fatal: Invalid revision range 0000000000000000000000000000000000000000..f974f26cb16cc6fe3946f163c787a05e713fb77b + + It appears that this can be ignored... 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_31-branch 2.31 + git clone ssh://sourceware.org/git/binutils-gdb.git -b binutils-2_33-branch 2.33 If you get a message about being in a "detached head" state, something has gone wrong... + Keep the checked out sources - they are going to be needed in future + steps. + 6. Update "BINUTILS_BRANCH" in gdbadmin's crontab: Log in as gdbadmin on sourceware.org, and then: @@ -62,7 +71,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.30 (HEAD)" to 2.30, and create "2.31 + new one. E.g. rename "2.33 (HEAD)" to 2.33, and create "2.34 (HEAD)": https://sourceware.org/bugzilla/editversions.cgi?product=binutils @@ -70,36 +79,67 @@ 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.31.51]) + m4_define([BFD_VERSION], [2.33.51]) 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.30.90]) + m4_define([BFD_VERSION], [2.32.90]) Regenerate various files on both branch and HEAD by configuring - with --enable-maintainer-mode. NB/ Remember to build gold and - gprof. Add ChangeLog entries. Commit the changes. Make sure - that this includes the .pot files as well as the configure and - makefiles. + with "--enable-maintainer-mode --enable-gold" and then building + with "make all-binutils all-gas all-gold all-gprof all-ld" + + Add ChangeLog entries for the updated files. Commit the changes. + Make sure that this includes the .pot files as well as the + configure and makefiles. 8. Create an initial prerelease: a. Create a source tarball of the BRANCH sources: + cd ./src-release -x binutils b. Build a test target using this tarball. - c. Upload the prerelease snapshot to the FTP: + cp binutils-.tar.xz /dev/shm + cd /dev/shm + tar xvf binutils-.tar.xz + mkdir build + cd build + ..//configure --quiet --enable-gold + make + + If there are problems, fix them. - scp ../binutils-$version.tar.xz sourceware.org:~ftp/pub/binutils/snapshots - ssh sourceware.org md5sum ~ftp/pub/binutils/snapshots/binutils-$version.tar.xz + c. Upload the prerelease 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 d. Clean up the source directory. - 9. Tell the Translation Project where to find the new tarball. + rm binutils- binutils-.tar binutils-.tar.xz + rm gas/bfin-lex.c \ + gas/bfin-parse.c \ + gas/bfin-parse.h \ + gas/itbl-lex.c \ + gas/itbl-parse.c \ + gas/itbl-parse.h \ + gas/m68k-parse.c \ + gas/rl78-parse.c \ + gas/rl78-parse.h \ + gas/rx-parse.c \ + gas/rx-parse.h \ + gold/yyscript.c \ + gold/yyscript.h + rm -fr proto-toplev + + 9. Tell the Translation Project where to find the new tarball. + qv: http://translationproject.org/html/maintainers.html ------------------------------------------------------------------------ @@ -155,34 +195,47 @@ When the time comes to actually make the release.... 20. Make sure that the branch sources still build, test and install - correctly. + correctly. Make sure that the sources are clean, without any + patch files (.reg .orig *~) left over. + + cd + cvsclean | xargs rm 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 - to set the value to "false". Regenerate the configure and - makefiles. Add changelog entries for the updates and add a - "this-is-the-2.XX-release" commit and commit. Make sure to - include the .gmo files. + 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.XX-release" comment and + commit. Make sure to include the .gmo files. 22. Check that your file creation mask will create the correct file permissions. Eg: - umask 022 + % umask + 22 + + Remove any spurious autom4te.cache files left over from the + reconfiguring: - 23. Create the release tarballs: + % find . -depth -name autom4te.cache -exec rm -r {} \; + + 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 + DEVO_SUPPORT variable in the src-release.sh script. If they are + needed then add them. + + Create the release tarballs: - ./src-release -b -g -l -x binutils + ./src-release.sh -b -g -l -x binutils 24. Check that the files in the tarballs have the correct - permissions. FIXME: The tarballs will contain spurious - autom4te.cache directories which could be removed to reduce - their size. + permissions. 25. Sanity check the release on x86_64-pc-linux-gnu by building and - running the testsuite. Make the source directory read-only - before building. Also test "make install". If necessary fix - any problems. + 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. 26. Tag the branch with the new release number: @@ -193,15 +246,7 @@ When the time comes to actually make the release.... NB/ If you do sign the binaries make sure to use a key that has been published with the FSF. - 27. Clean up the source tree. (Use "git status" to find new - files, and remove them). - - 28. Edit bfd/development.sh on the branch and set - "development=true". Also bump the version by adding a trailing - .0, so that the date suffix keeps the version lower than the - trunk version. Regenerate files. Commit these changes. - - 29. Upload the tarballs to ftp.gnu.org. + 27. Upload the tarballs to ftp.gnu.org. gnupload --to ftp.gnu.org:binutils binutils-X.XX.tar.* @@ -210,7 +255,7 @@ When the time comes to actually make the release.... Check for an email response from the upload. If necessary fix any problems. - 30. Upload the tarballs (and signatures) to sourceware.org: + 28. Upload the tarballs (and signatures) to sourceware.org: sftp sourceware.org cd /sourceware/ftp/pub/binutils/releases @@ -221,30 +266,69 @@ When the time comes to actually make the release.... FIXME: Should the signatures (created by the gnupload script in step 29) be uploaded as well ? - 31. Update web pages. For sourceware.org: + 29. Update web pages. For sourceware.org: Create a new documentation folder on the sourceware.org web pages as /sourceware/www/sourceware/htdocs/binutils/docs-X.XX. + + sftp sourceware.org + cd /sourceware/www/sourceware/htdocs/binutils + mkdir docs-X.XX + cd docs-X.XX + mkdir as bfd binutils gprof ld + cd ../docs-X.(XX-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. + + cd ../docs-X.XX + put index.html + Make the html documentation locally with the "make html" command - and then upload and rename the directories as needed. Create an - index.html file and then edit the docs link to point to the new - docs-X.XX directory. - - Update the sourceware.org site to point to the new documentation - and mention the new version. + and then upload and rename the directories as needed. (sftp + does not appear to support recursive uploads however, so the + directories will have to be made by hand). + + cd as + lcd /gas/doc/as.html + put * + cd ../bfd + lcd ../../../bfd/doc/bfd.html + put * + cd ../binutils + lcd ../../../binutils/doc/binutils.html + put * + cd ../gprof + lcd ../../../gprof/gprof.html + put * + cd ../ld + lcd ../../ld/ld.html + put * + + Edit the top level binutils index.html file to change the links + to the new documentation. + + cd ../../.. + get indexl.html + [edit] + put index.html + quit + + Check that the new web page is correct. For the www.gnu.org site you have to email webmasters@gnu.org and ask them to make the change(s). - 32. Send emails to binutils@sourceware.org, info-gnu@gnu.org and + 30. Send emails to binutils@sourceware.org, info-gnu@gnu.org and David Edelsohn announcing the new release. Sign the email and include the checksum. (The email to Davis is so that he can update the GNU Toolchain social media). Something like this: - ------------------------------------------------------------------------ + ----------------------------------------------------------------------- Hi Everyone, - We are pleased to announce that version 2.XX of the Binutils project + We are pleased to announce that version 2.XX of the GNU Binutils project sources have been released and are now available for download at: https://ftp.gnu.org/gnu/binutils @@ -260,8 +344,41 @@ When the time comes to actually make the release.... Our thanks go out to all of the binutils contributors, past and present, for helping to make this release possible. - -------------------------------------------------------------------------- + ----------------------------------------------------------------------- + + 31. Clean up the source tree. (Use "git status" to find new + files, and remove them). + rm binutils- binutils-.tar binutils-.tar.xz + rm gas/bfin-lex.c \ + gas/bfin-parse.c \ + gas/bfin-parse.h \ + gas/itbl-lex.c \ + gas/itbl-parse.c \ + gas/itbl-parse.h \ + gas/m68k-parse.c \ + gas/rl78-parse.c \ + gas/rl78-parse.h \ + gas/rx-parse.c \ + gas/rx-parse.h \ + gold/yyscript.c \ + gold/yyscript.h + rm -fr proto-toplev + + 32. Edit bfd/development.sh on the branch and set the development flag + to "true". (Leave the experimental flag set to "false"). Also bump + the version in bfd/version.m4 by adding a trailing .0, so that the + date suffix keeps the version lower than the trunk version. + Regenerate files. Commit these changes. + + 33. Email the binutils list telling everyone that the 2.XX branch + 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. + ------------------------------------------------- How to perform a point release. ------------------------------------------------- @@ -292,8 +409,13 @@ looks like this: 3. In the branch sources: a. Update the minor release number in bfd/version.m4. - b. Edit bfd/development.sh and set "development=false". + b. Edit bfd/development.sh, set "development=false" and + "experimental=false". c. Regenerate the configure files. + c.1. Remove spurious autom4te.cache files: + + find . -depth -name autom4te.cache -exec rm -r {} \; + d. Commit the updates along with a "this-is-the-2.XX.X-release" note in all of the changelogs. e. Tag the branch with the new release number: @@ -318,9 +440,6 @@ looks like this: k. Clean up the source tree. (Use "git status" to find new files, and remove them). - FIXME: The tarballs will contain spurious autom4te.cache - directories which could be removed to reduce their size. - 4. [If paranoid - upload the tarballs to one of the FTP servers and ask people to test it before going on to step 5]. @@ -333,18 +452,17 @@ looks like this: 6. Upload the tarballs to sourceware.org: sftp sourceware.org - cd /ftp/pub/binutils/releases + cd /sourceware/ftp/pub/binutils/releases put binutils-X.XX.X.tar.* chmod 644 binutils-X.XX.X.tar.* quit - FIXME: Should the signatures (created by the gnupload script in - step 5) be uploaded as well ? + It is OK to upload the signatures as well. 7. Update web pages. For sourceware.org: * Log on to sourceware.org - * Go /www/htdocs/binutils + * Go to /sourceware/www/sourceware/htdocs/binutils * Edit index.html For the www.gnu.org site you have to email webmasters@gnu.org @@ -357,8 +475,8 @@ looks like this: ------------------------------------------------------------------------ Hi Everyone, - We are pleased to announce that version 2.XX.X of the Binutils project - sources have been released and are now available for download at: + We are pleased to announce that version 2.XX.X of the GNU Binutils + project sources have been released and are now available for download at: https://ftp.gnu.org/gnu/binutils https://sourceware.org/pub/binutils/releases/ @@ -377,7 +495,7 @@ Hi Everyone, -------------------------------------------------------------------------- -Copyright (C) 2017-2018 Free Software Foundation, Inc. +Copyright (C) 2017-2019 Free Software Foundation, Inc. Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright