Release Process for Linaro GDB
The GDB source code now resides in a git repository that is shared with binutils.
Linaro mirrors this new repository at the following location:
This document describes the process of creating Linaro releases of stable GDB releases using this repository.
For each upstream GDB stable branch release Linaro will have a corresponding Linaro GDB branch that lives within the Linaro mirror.
Check to see if there is an up-to-date Linaro branch that tracks the latest stable release branch from upstream. This will determine whether a new Linaro branch of GDB needs to be created or if an existing Linaro branch should be updated for this release.
Note: For the purpose of this process document release version XX represents the current latest upstream stable release number, and version WW indicates the previous version.
Start by cloning a fresh source tree and looking at the available GDB branches. You will be doing a git push, so you need permissions to push to the repository and will need to use the ssh:// protocol for your checkout (otherwise you have to specify the remote url directly during your push).
git clone ssh://git.linaro.org/toolchain/binutils-gdb.git cd binutils-gdb.git
- Look at the upstream GDB branches that have been released:
git branch -a | grep gdb
Compare the latest gdb-7.YY-branch branch to the latest Linaro GDB branch:
git branch -a | grep linaro | grep gdb
If the latest Linaro GDB branch is linaro_gdb-7.WW-branch and the latest upstream stable branch is gdb-7.XX-branch then a new Linaro branch of GDB needs to be created. Proceed to the section entitled Create a New Linaro Branch of GDB.
Otherwise proceed to the section entitled Updating an Existing Linaro Branch of GDB.
Creating a New Linaro Branch of GDB
- Create a new Linaro branch of GDB:
git checkout -b local_linaro_gdb-7.XX-branch origin/gdb-7.XX-branch
- Ensure branding has been applied to gdb/configure.ac and gdb/gdbserver/configure.ac and the configures have been regenerated.
- Ensure src-release has been modified for the Linaro release process.
Update the gdb/ChangeLog.linaro file to indicate that a new Linaro branch of GDB has been created (though not yet 'released').
20XX-XX-XX First Last <[email protected]> Linaro gdb 7.XX branch created.
Add the modified gdb/ChangeLog.linaro file.
git add gdb/ChangeLog.linaro
- Commit the changes to the local branch.
- Create a version relevant git commit message:
Created Linaro branch of GDB 7.YY.
- Since the newly created branch already tracks the latests updates to the tracked branch the section on merging from the tracked branch can be skipped.
Push the new branch to the Linaro binutils-gdb.git repository.
git push origin local_linaro_gdb-7.YY-branch:linaro_gdb-7.YY-branch
Proceed to the section entitled Cherry-picking Changes from the Upstream Master Branch.
Updating an Existing Linaro Branch of GDB
- Check out a local copy of the existing Linaro branch of GDB:
git checkout -b local_linaro_gdb-7.XX-branch origin/linaro_gdb-7.XX-branch
Proceed to the section entitled Merging Changes From the Tracked Branch.
Merging Changes from the Tracked Branch
Since the last time the Linaro branch was released the tracked upstream stable release branch might have had updates. These updates need to be merged into the linaro_gdb-7.XX-branch.
- Update the git remotes with the latest version of the upstream branch.
git fetch origin
Merge the tracked branch changes into the current branch. This will add a series of commits to your local_linaro_gdb-7.XX-branch.
git merge origin/gdb-7.XX-branch
These changes will be pushed to the linaro_gdb-7.XX-branch in a later step (once the release is tagged).
If there is a conflict during the merge proceed to the section entitled Dealing With Merge Conflicts from the Tracked Branch.
Otherwise Proceed to the section entitled Cherry-picking Changes from the Upstream Master Branch.
Dealing With Merge Conflicts from the Tracked Branch
In the event that an upstream feature was backported into the Linaro release branch before it was backported into the stable upstream release branch it might happen that the upstream release branch picks up change in the future. At this point, a Linaro release update (via a git merge) might create a conflict.
- Back out the erroneous merge
- Revert the patch that was applied to the Linaro branch by reverse applying the patch.
- Restart the merge (and hope the conflict goes away).
// TODO: Add git commands for above
Cherry-picking Changes from the Upstream Master Branch
After merging in the changes from the upstream release branch (if necessary) determine if the upstream stable release branch that the current Linaro branch release is tracking does not yet contain a feature that is desired for the current Linaro branch of Binutils. If so it will be necessary to cherry-pick that upstream feature from the master branch into the Linaro branch.
- Look at the commit log of the upstream master branch.
git log origin/master
- Find the commit-id of the feature in the log, e.g. 1234567
- Attempt to cherry-pick the upstream feature into the existing branch. If successful this will automatically commit the fix to the local Linaro release branch.
git cherry-pick [-x] 1234567
If there is a failure then resolve the conflict and git commit -c.
Update the directory relative ChangeLog.linaro files that correspond to the cherry-picked commit. For instance if the cherry-picked change modified files in the bfd/ directory copy the ChangeLog entry that the commit added to bfd/ChangeLog onto the top of bfd/ChangeLog.linaro. This is most easily done by using git show 1234567 and visually determining which ChangeLog files have been modified.
Commit the changes to the ChangeLog.linaro files.
git add -A git commit
Proceed to the section entitled Updating the Linaro Branch Release Information.
Updating the Linaro Branch Release Information
The branch needs to have the version number updated.
Add a ChangeLog entry to the start of gdb/ChangeLog.linaro:
20XX-XX-XX First Last <[email protected]> Linaro gdb 7.XX-20XX.XX[-X] released. * version.in: Update VERSION.
Note on release numbers: The main release for a given month's milestone is called 7.XX-20XX.XX (e.g. 7.6.1-2013.06). Subsequent respins (if necessary) carry an additional respin number, starting at 1 (e.g. 7.6.1-2013.06-1).
- Check in the changes
git commit -a
- Tag the release
git tag -a linaro_gdb-7_XX-20XX_XX[-X]_release
Push the tags to the Linaro binutils-gdb.git repository mirror.
git push --tags
Create the tarballs
- Export the sources
git archive --format=tar --prefix=gdb-export/ HEAD | (cd .. && tar xf - )
- Switch to the new source tree
- Run the release script
This will build all generated files and package the release tarball.
./src-release.sh -x gdb
- Save the tarfile:
mv gdb-7.XX-20XX.XX-X.tar.xz ../
Bump the development version number
- Change directory back to the binutils repository
(where Y is the number of the next respin, or 1 if this was the main release).
Add this to the start of gdb/ChangeLog.linaro:
20XX-XX-XX First Last <[email protected]> * version.in: Bump version.
- Check in all of the changes
git commit -a git push
Verify the release
- Build and test the release sources as thoroughly as possible.
- Build GDB and run the testsuite on ARM, AArch64, and x86
Publishing the release
WorkingGroups/ToolChain/GDB/ReleaseProcess (last modified 2014-08-29 16:35:15)