projects / deliverable / binutils-gdb.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
Fix spelling mistakes.
[deliverable/binutils-gdb.git] / binutils / README-how-to-make-a-release
diff --git a/binutils/README-how-to-make-a-release b/binutils/README-how-to-make-a-release
index c46ba7c4a5d061d3db344198e91113a2c6998c00..47af677a9e3d834dac87ae63836197ef213ace93 100644 (file)
--- a/binutils/README-how-to-make-a-release
+++ b/binutils/README-how-to-make-a-release
@@ -31,7 +31,6 @@ How to perform a release.
        [If using the make-prerelease.sh script, check that
         common.sh has the right values].
        [make-prelease.sh command i]
        [If using the make-prerelease.sh script, check that
         common.sh has the right values].
        [make-prelease.sh command i]
-       [make-prelease.sh command C]
      Likewise for all of the ChangeLog files.
      Add a note of the name of the new branch to binutils/BRANCHES.
      Commit these changes.
      Likewise for all of the ChangeLog files.
      Add a note of the name of the new branch to binutils/BRANCHES.
      Commit these changes.
@@ -39,10 +38,17 @@ How to perform a release.
 
   4. Create the release branch using:
 
 
   4. Create the release branch using:
 
-       git tag -a binutils-2_30-branch   [e.g. for the 2.30 branch...]
-        git push --tags origin binutils-2_30-branch
+       git branch binutils-2_31-branch
+        git push origin binutils-2_31-branch
 
 
-  5. Update "BINUTILS_BRANCH" in gdbadmin's crontab:
+  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
+
+     If you get a message about being in a "detached head" state, something
+     has gone wrong...
+
+  6. Update "BINUTILS_BRANCH" in gdbadmin's crontab:
 
      Log in as gdbadmin on sourceware.org, and then:
 
 
      Log in as gdbadmin on sourceware.org, and then:
 
@@ -55,78 +61,92 @@ How to perform a release.
      If you do not have access to this account, please feel free to
      ask Joel Brobecker <brobecker AT adacore DOT com>.
 
      If you do not have access to this account, please feel free to
      ask Joel Brobecker <brobecker AT adacore DOT com>.
 
-  6. Update bfd/configure and bfd/configure.ac on HEAD to indicate
-     snapshot of the following release.
-       [make-prerelease.sh command hv + C]
-
   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
      (HEAD)":
      
         https://sourceware.org/bugzilla/editversions.cgi?product=binutils
 
   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
      (HEAD)":
      
         https://sourceware.org/bugzilla/editversions.cgi?product=binutils
 
-  8. Update the release number in bfd/version.m4 for the mainline and
-     the branch.  The mainline should have the minor number
-     incremented, but the branch only needs the point value set to 90
-     as the release has not actually happened yet.
+  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])
+       
+     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])
 
      Regenerate various files on both branch and HEAD by configuring
      with --enable-maintainer-mode.  NB/ Remember to build gold and
 
      Regenerate various files on both branch and HEAD by configuring
      with --enable-maintainer-mode.  NB/ Remember to build gold and
-     gprof.  Commit the changes.  Make sure that this includes the
-     .pot files as well as the configure and makefiles.
+     gprof.  Add ChangeLog entries.  Commit the changes.  Make sure
+     that this includes the .pot files as well as the configure and
+     makefiles.
 
 
-  9. Create an initial prerelease:
+  8. Create an initial prerelease:
 
 
-     a. Change the version on the branch (bfd/version.m4), regenerate
-        the files, and check this in.
-
-     b. Create a source tarball of the branch sources:
+     a. Create a source tarball of the BRANCH sources:
 
            ./src-release -x binutils
 
 
            ./src-release -x binutils
 
-     c. Build a test target using this tarball.
+     b. Build a test target using this tarball.
 
 
-     d. Upload the prerelease snapshot to the FTP:
+     c. Upload the prerelease snapshot to the FTP:
 
           scp ../binutils-$version.tar.xz sourceware.org:~ftp/pub/binutils/snapshots
           ssh sourceware.org md5sum ~ftp/pub/binutils/snapshots/binutils-$version.tar.xz
 
 
           scp ../binutils-$version.tar.xz sourceware.org:~ftp/pub/binutils/snapshots
           ssh sourceware.org md5sum ~ftp/pub/binutils/snapshots/binutils-$version.tar.xz
 
-  10. Send it to the Translation Project:
+     d. Clean up the source directory.
+
+   9. Tell the Translation Project where to find the new tarball. <coordinator@translationproject.org>
+      qv: http://translationproject.org/html/maintainers.html
+
+------------------------------------------------------------------------
+Dear Translation Project
+
+  The 2.31 release branch has been created for the FSF binutils.
+
+  A snapshot of the branch sources can be found here:
 
 
-        http://translationproject.org/html/maintainers.html
+    https://sourceware.org/pub/binutils/snapshots/binutils-2.30.90.tar.xz
 
 
-      Sending mail for one of the POT files is sufficient.
+  We hope to make the official release of the sources on the 8th July
+  although that could change if there are important bugs that need to
+  be fixed before the release.
+------------------------------------------------------------------------
 
 
-  11. Announce the availability of the snapshot and the branch on the
+  10. Announce the availability of the snapshot and the branch on the
       binutils mailing list.  Set a date for when the release will
       actually happen.  Something like:
       binutils mailing list.  Set a date for when the release will
       actually happen.  Something like:
-        ------------------------------------------------------------------------
-        Hi Everyone, 
-       
-          The 2.XX branch has now been created:
-
-             git clone git://sourceware.org/git/binutils-gdb.git -b binutils-2_XX-branch 2.XX
-
-          A snapshot of the sources is also available here:
-
-            ftp://sourceware.org/pub/binutils/snapshots/binutils-2.XX.0.tar.xz
-
-          Please could all patches for the branch be run by me.
-          The rules for the branch are:
-        
-            * No new features.
-            * Target specific bug fixes are OK.
-            * Generic bug fixes are OK if they are important and widely tested.
-            * Documentation updates/fixes are OK.
-            * Translation updates are OK.
-            * Fixes for testsuite failures are OK.
-        
-          Ideally I would like to make the release happen in two weeks time,
-          i.e. Saturday 27th Jan.  Which I hope will be enough time for everyone
-          to get their final fixes in.
-        ------------------------------------------------------------------------
-
-  12. Build various different toolchains, test them and nag
+      
+------------------------------------------------------------------------
+Hi Everyone, 
+
+  The 2.XX branch has now been created:
+
+     git clone git://sourceware.org/git/binutils-gdb.git -b binutils-2_XX-branch 2.XX
+
+  A snapshot of the sources is also available here:
+
+    https://sourceware.org/pub/binutils/snapshots/binutils-2.XX.90.tar.xz
+
+  Please could all patches for the branch be run by me.
+  The rules for the branch are:
+
+    * No new features.
+    * Target specific bug fixes are OK.
+    * Generic bug fixes are OK if they are important and widely tested.
+    * Documentation updates/fixes are OK.
+    * Translation updates are OK.
+    * Fixes for testsuite failures are OK.
+
+  Ideally I would like to make the release happen in two weeks time,
+  i.e. Saturday 27th Jan.  Which I hope will be enough time for everyone
+  to get their final fixes in.
+------------------------------------------------------------------------
+
+  11. Build various different toolchains, test them and nag
       maintainers to fix any testsuite failures for their
       architectures...
 
       maintainers to fix any testsuite failures for their
       architectures...
 
GDB Binutils - Deliverables
This page took 0.040505 seconds and 4 git commands to generate.