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.
This commit is contained in:
parent
9c0f3d3f20
commit
ef336cb09a
@ -1,3 +1,8 @@
|
||||
2017-10-05 Nick Clifton <nickc@redhat.com>
|
||||
|
||||
* README-how-to-make-a-release: Merge steps 3, 4 and 5, and insert
|
||||
the git tag operation at the correct location.
|
||||
|
||||
2017-10-05 Alan Modra <amodra@gmail.com>
|
||||
|
||||
PR 22239
|
||||
|
@ -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:
|
||||
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 -u XXXXX to sign with a gpg key]
|
||||
[optional -f to move an already created tag]
|
||||
|
||||
git push origin
|
||||
git tag -a binutils-2_XX_X
|
||||
[optional: add "-u XXXXX" to sign with a gpg key]
|
||||
git push origin binutils-2_XX_X
|
||||
|
||||
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.
|
||||
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,
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user