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:
ask Joel Brobecker <brobecker AT adacore DOT com>.
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
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 <branch-sources>
./src-release -x binutils
b. Build a test target using this tarball.
- c. Upload the prerelease snapshot to the FTP:
+ cp binutils-<version>.tar.xz /dev/shm
+ cd /dev/shm
+ tar xvf binutils-<version>.tar.xz
+ mkdir build
+ cd build
+ ../<version>/configure --quiet --enable-gold
+ make
- scp ../binutils-$version.tar.xz sourceware.org:~ftp/pub/binutils/snapshots
- ssh sourceware.org md5sum ~ftp/pub/binutils/snapshots/binutils-$version.tar.xz
+ If there are problems, fix them.
+
+ c. Upload the prerelease snapshot to the sourceware FTP site:
+
+ cd <branch-sources>
+ scp binutils-<version>.tar.xz sourceware.org:~ftp/pub/binutils/snapshots
+ ssh sourceware.org md5sum ~ftp/pub/binutils/snapshots/binutils-<version>.tar.xz
d. Clean up the source directory.
- 9. Tell the Translation Project where to find the new tarball. <coordinator@translationproject.org>
+ rm binutils-<version> binutils-<version>.tar binutils-<version>.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.
+ <coordinator@translationproject.org>
qv: http://translationproject.org/html/maintainers.html
------------------------------------------------------------------------
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:
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. (sftp
does not appear to support recursive uploads however, so the
- directories will have to be made by hand). Create an
- index.html file and then edit the docs link to point to the new
- docs-X.XX directory.
-
- Update the index.html file in the directory containing the
- docs-X.XX entries to point to the new documentation and mention
- the new version.
+ directories will have to be made by hand).
+
+ cd as
+ lcd <build-dir>/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).
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 GNU Binutils project
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).
- 32. Edit bfd/development.sh on the branch and set
- "development=true". 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.31 branch
+ rm binutils-<version> binutils-<version>.tar binutils-<version>.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.
-------------------------------------------------
projects / deliverable / binutils-gdb.git / blobdiff