diff options
author | Nick Clifton <nickc@redhat.com> | 2017-10-05 10:52:04 +0100 |
---|---|---|
committer | Nick Clifton <nickc@redhat.com> | 2017-10-05 10:52:04 +0100 |
commit | ef336cb09a4193b3c86284a875c7bc4c2978bfad (patch) | |
tree | 1548d306b193aa80f558f86d61418460f6d39ec0 /binutils/README-how-to-make-a-release | |
parent | 9c0f3d3f2017829ffd908c9893b85094985c3b58 (diff) | |
download | gdb-ef336cb09a4193b3c86284a875c7bc4c2978bfad.zip gdb-ef336cb09a4193b3c86284a875c7bc4c2978bfad.tar.gz gdb-ef336cb09a4193b3c86284a875c7bc4c2978bfad.tar.bz2 |
Update README-how-to-make-a-release with the correct sequence for creating the source tarball.
* README-how-to-make-a-release: Merge steps 3, 4 and 5, and insert
the git tag operation at the correct location.
Diffstat (limited to 'binutils/README-how-to-make-a-release')
-rw-r--r-- | binutils/README-how-to-make-a-release | 68 |
1 files changed, 29 insertions, 39 deletions
diff --git a/binutils/README-how-to-make-a-release b/binutils/README-how-to-make-a-release index da0e8a8..c87f27e 100644 --- a/binutils/README-how-to-make-a-release +++ b/binutils/README-how-to-make-a-release @@ -45,46 +45,39 @@ looks like this: 2. Make sure that the branch sources build, test and install correctly. - 3. In the branch sources... + 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. + a. Update the minor release number in bfd/version.m4. + b. Edit bfd/development.sh and set "development=false". + c. Regenerate the configure files. + 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: + + git tag -a binutils-2_XX_X + [optional: add "-u XXXXX" to sign with a gpg key] + git push origin binutils-2_XX_X + + f. Create the release tarballs: + ./src-release -b -g -l -x binutils + g. Edit bfd/development.sh and set "development=true". + h. Commit this change into the git repository. + i. 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. - 6. [If paranoid - upload the tarballs to one of the FTP servers and - ask people to test it before going on to step 7]. + 4. [If paranoid - upload the tarballs to one of the FTP servers and + ask people to test it before going on to step 5]. - 7. Upload the tarballs to ftp.gnu.org. + 5. 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. + The gnupload script is in the gnulib/build-aux directory. - 8. Upload the tarballs to sourceware.org: + 6. Upload the tarballs to sourceware.org: sftp sourceware.org cd /ftp/pub/binutils/releases @@ -93,12 +86,9 @@ looks like this: quit FIXME: Should the signatures (created by the gnupload script in - step 7) be uploaded as well ? + step 5) 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: + 7. Update web pages. For sourceware.org: * Log on to sourceware.org * Go /www/htdocs/binutils @@ -107,10 +97,10 @@ looks like this: 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: + 8. 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, |