From 78b2179a8e085b34ad7872450e5fadff4f7e5eb0 Mon Sep 17 00:00:00 2001 From: Nick Clifton Date: Tue, 26 Sep 2017 10:07:23 +0100 Subject: [PATCH] Add README file for creating binutils releases --- binutils/ChangeLog | 4 + binutils/README-how-to-make-a-release | 135 ++++++++++++++++++++++++++++++++++ 2 files changed, 139 insertions(+) create mode 100644 binutils/README-how-to-make-a-release diff --git a/binutils/ChangeLog b/binutils/ChangeLog index 2b50930..80fff9c 100644 --- a/binutils/ChangeLog +++ b/binutils/ChangeLog @@ -1,3 +1,7 @@ +2017-09-26 Nick Clifton + + * README-how-to-make-a-release: New file. + 2017-09-26 Alan Modra PR 21732 diff --git a/binutils/README-how-to-make-a-release b/binutils/README-how-to-make-a-release new file mode 100644 index 0000000..da0e8a8 --- /dev/null +++ b/binutils/README-how-to-make-a-release @@ -0,0 +1,135 @@ + README for MAKING BINUTILS RELEASES + +This is a collection of notes on how to perform a binutils release. A +lot of this information can also be found in the maintain.texi file in +the gnulib project: + + https://www.gnu.org/software/gnulib/ + +It is useful to have a cloned copy of the sources of this project as +it also contains an upload script used to install tarballs on the GNU +FTP server. + +Make sure that you have upload authority on sourceware and fencepost. +Beware - this is an involved process and can take weeks to complete. +See the maintain.texi file for details on how to obtain these +permissions. + +------------------------------------------------- +How to perform a release. +------------------------------------------------- + +xxx -- fill in stuff here -- xxx + +------------------------------------------------- +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 +translations updated and the documentation uploaded. So the procedure +looks like this: + + 0. Decide that a point release is necessary. + + Usually this only happens when a sufficient number of serious + bugs have been found and fixed since the previous release, and a + new official release is not imminent. + + 1. Tell the community that a point release is happening. Ask + maintainers to ensure that their ports are up to date on the + release branch. Ask the community if there are any bug fixes + which are missing from the branch. Allow some time for the + responses to this step. + + 2. Make sure that the branch sources build, test and install + correctly. + + 3. In the branch sources... + + Update the minor release number in bfd/version.m4. + Regenerate the configure files. + Commit the updates along with a "this-is-the-2.XX.X-release" note + in the changelogs. + + 4. Tag the branch with the new release number: + + git tag -a binutils-2_XX_X + [optional -u XXXXX to sign with a gpg key] + [optional -f to move an already created tag] + + git push origin + + 5. Create the release tarballs: + + a. Edit bfd/development.sh and set "development=false". + b. ./src-release -b -g -l -x binutils + c. Edit bfd/development.sh and set "development=true". + + FIXME: Really the development.sh file should be changed by the + src-release script on the fly. The development=false flag only + wants to be set in the release tarballs however, not the branch + sources as the branch will continue to have (development) patches + checked in to it. + + FIXME: The tarballs will contain spurious autom4te.cache + directories which could be removed to reduce their size. + + 6. [If paranoid - upload the tarballs to one of the FTP servers and + ask people to test it before going on to step 7]. + + 7. Upload the tarballs to ftp.gnu.org. + + gnupload --to ftp.gnu.org:binutils binutils-X.XX.X.tar.* + + gnupload is in the gnulib/build-aux directory. + + 8. Upload the tarballs to sourceware.org: + + sftp sourceware.org + cd /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 7) be uploaded as well ? + + 9. Clean up the source tree. (Use "git status" to find new files, + and remove them). + + 10. Update web pages. For sourceware.org: + + * Log on to sourceware.org + * Go /www/htdocs/binutils + * Edit index.html + + For the www.gnu.org site you have to email webmasters@gnu.org + and ask them to make the change(s). + + 11. Send an emails to the binutils list, info-gnu@gnu.org and + David Edelsohn announcing the new release. + (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.X of the 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/ + + This is a point release over the previous 2.XX version, containing bug + fixes but no new features. + + Our thanks go out to all of the binutils contributors, past and + present, for helping to make this release possible. +-------------------------------------------------------------------------- + + +Copyright (C) 2017 Free Software Foundation, Inc. + +Copying and distribution of this file, with or without modification, +are permitted in any medium without royalty provided the copyright +notice and this notice are preserved. -- 2.7.4