diff options
author | Nick Clifton <nickc@redhat.com> | 2017-09-26 10:07:23 +0100 |
---|---|---|
committer | Nick Clifton <nickc@redhat.com> | 2017-09-26 10:07:23 +0100 |
commit | 78b2179a8e085b34ad7872450e5fadff4f7e5eb0 (patch) | |
tree | 55c4743c09ba8f6a054d00d9f104e98d6b136e3c /binutils | |
parent | df8899e5c8b60ffbbe93e35315ebb76a9c80ee37 (diff) | |
download | fsf-binutils-gdb-78b2179a8e085b34ad7872450e5fadff4f7e5eb0.zip fsf-binutils-gdb-78b2179a8e085b34ad7872450e5fadff4f7e5eb0.tar.gz fsf-binutils-gdb-78b2179a8e085b34ad7872450e5fadff4f7e5eb0.tar.bz2 |
Add README file for creating binutils releases
Diffstat (limited to 'binutils')
-rw-r--r-- | binutils/ChangeLog | 4 | ||||
-rw-r--r-- | binutils/README-how-to-make-a-release | 135 |
2 files changed, 139 insertions, 0 deletions
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 <nickc@redhat.com> + + * README-how-to-make-a-release: New file. + 2017-09-26 Alan Modra <amodra@gmail.com> 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 <dje.gcc@gmail.com> 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. |