18 Versions and Branches
gdb's version is determined by the file gdb/version.in and takes one of the following forms:
- an official release (e.g., 6.2 or 6.2.1)
- a snapshot taken at YYYY-MM-DD-gmt (e.g.,
188.8.131.5220302, 184.108.40.20620304, or 220.127.116.1120308)
- a cvs check out drawn on YYYY-MM-DD (e.g.,
18.104.22.16820302-cvs, 22.214.171.12420304-cvs, or 126.96.36.19920308-cvs)
- major.minor.patchlevel.YYYYMMDD (vendor)
- a vendor specific release of gdb, that while based on
major.minor.patchlevel.YYYYMMDD, may include additional changes
gdb's mainline uses the major and minor version numbers from the most recent release branch, with a patchlevel of 50. At the time each new release branch is created, the mainline's major and minor version numbers are updated.
gdb's release branch is similar. When the branch is cut, the patchlevel is changed from 50 to 90. As draft releases are drawn from the branch, the patchlevel is incremented. Once the first release (major.minor) has been made, the patchlevel is set to 0 and updates have an incremented patchlevel.
For snapshots, and cvs check outs, it is also possible to identify the cvs origin:
- drawn from the head of mainline cvs (e.g., 188.8.131.5220302)
- major.minor.91.YYYYMMDD ...
- drawn from a release branch prior to the release (e.g.,
- major.minor.1.YYYYMMDD ...
- drawn from a release branch after the release (e.g., 184.108.40.20620308)
If the previous gdb version is 6.1 and the current version is 6.2, then, substituting 6 for major and 1 or 2 for minor, here's an illustration of a typical sequence:
<HEAD> | 220.127.116.1120302-cvs | +--------------------------. | <gdb_6_2-branch> | | 18.104.22.16820303-cvs 6.1.90 (draft #1) | | 22.214.171.12420304-cvs 126.96.36.19920304-cvs | | 188.8.131.5220305-cvs 6.1.91 (draft #2) | | 184.108.40.20620306-cvs 220.127.116.1120306-cvs | | 18.104.22.16820307-cvs 6.2 (release) | | 22.214.171.12420308-cvs 126.96.36.19920308-cvs | | 188.8.131.5220309-cvs 6.2.1 (update) | | 184.108.40.20620310-cvs <branch closed> | 220.127.116.1120311-cvs | +--------------------------. | <gdb_6_3-branch> | | 18.104.22.16820312-cvs 6.2.90 (draft #1) | |
18.2 Release Branches
gdb_major_minor-YYYYMMDD-branchpoint gdb_major_minor-branch gdb_major_minor-YYYYMMDD-release
Pragmatics: To help identify the date at which a branch or release is made, both the branchpoint and release tags include the date that they are cut (YYYYMMDD) in the tag. The branch tag, denoting the head of the branch, does not need this.
18.3 Vendor Branches
To avoid version conflicts, vendors are expected to modify the file gdb/version.in to include a vendor unique alphabetic identifier (an official gdb release never uses alphabetic characters in its version identifier). E.g., 6.2widgit2, or 6.2 (Widgit Inc Patch 2).
18.4 Experimental Branches
gdb permits the creation of branches, cut from the cvs repository, for experimental development. Branches make it possible for developers to share preliminary work, and maintainers to examine significant new developments.
The following are a set of guidelines for creating such branches:
- a branch has an owner
- The owner can set further policy for a branch, but may not change the
ground rules. In particular, they can set a policy for commits (be it
adding more reviewers or deciding who can commit).
- all commits are posted
- All changes committed to a branch shall also be posted to
the gdb patches mailing list. While commentary on such changes are encouraged, people
should remember that the changes only apply to a branch.
- all commits are covered by an assignment
- This ensures that all changes belong to the Free Software Foundation,
and avoids the possibility that the branch may become contaminated.
- a branch is focused
- A focused branch has a single objective or goal, and does not contain
unnecessary or irrelevant changes. Cleanups, where identified, being
be pushed into the mainline as soon as possible.
- a branch tracks mainline
- This keeps the level of divergence under control. It also keeps the
pressure on developers to push cleanups and other stuff into the
- a branch shall contain the entire gdb module
- The gdb module
gdbshould be specified when creating a branch (branches of individual files should be avoided). See Tags.
- a branch shall be branded using version.in
- The file gdb/version.in shall be modified so that it identifies the branch owner and branch name, e.g., 22.214.171.12430303_owner_name or 6.2 (Owner Name).
To simplify the identification of gdb branches, the following branch tagging convention is strongly recommended:
- The branch point and corresponding branch tag. YYYYMMDD is the
date that the branch was created. A branch is created using the
cvs rtag owner_name-YYYYMMDD-branchpoint gdb cvs rtag -b -r owner_name-YYYYMMDD-branchpoint \ owner_name-YYYYMMDD-branch gdb
- The tagged point, on the mainline, that was used when merging the branch
on yyyymmdd. To merge in all changes since the branch was cut,
use a command sequence like:
cvs rtag owner_name-yyyymmdd-mergepoint gdb cvs update \ -jowner_name-YYYYMMDD-branchpoint -jowner_name-yyyymmdd-mergepoint
Similar sequences can be used to just merge in changes since the last merge.
For further information on cvs, see Concurrent Versions System.