Next: Start of New Year Procedure, Previous: Porting GDB, Up: Top

## 19 Versions and Branches

### 19.1 Versions

gdb's version is determined by the file `gdb/version.in` and takes one of the following forms:

major.minor
major.minor.patchlevel
  an official release (e.g., 6.2 or 6.2.1)
major.minor.patchlevel.YYYY MM DD
  a snapshot taken at YYYY-MM-DD-gmt (e.g., 6.1.50.20020302, 6.1.90.20020304, or 6.1.0.20020308)
major.minor.patchlevel.YYYY MM DD-cvs
  a cvs check out drawn on YYYY-MM-DD (e.g., 6.1.50.20020302-cvs, 6.1.90.20020304-cvs, or 6.1.0.20020308-cvs)
major.minor.patchlevel.YYYY MM DD (vendor)
  a vendor specific release of gdb, that while based on
  major.minor.patchlevel.YYYY MM DD, 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:

major.minor.50.YYYY MM DD
  drawn from the head of mainline cvs (e.g., 6.1.50.20020302)
major.minor.90.YYYY MM DD
major.minor.91.YYYY MM DD ...
  drawn from a release branch prior to the release (e.g., 6.1.90.20020304)
major.minor.0.YYYY MM DD
major.minor.1.YYYY MM DD ...
  drawn from a release branch after the release (e.g., 6.2.0.20020308)

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>
                 |
         6.1.50.20020302-cvs
                 |
                 +--------------------------.
                 |                    <gdb_6_2-branch>
                 |                          |
         6.2.50.20020303-cvs        6.1.90 (draft #1)
                 |                          |
         6.2.50.20020304-cvs        6.1.90.20020304-cvs
                 |                          |
         6.2.50.20020305-cvs        6.1.91 (draft #2)
                 |                          |
         6.2.50.20020306-cvs        6.1.91.20020306-cvs
                 |                          |
         6.2.50.20020307-cvs        6.2 (release)
                 |                          |
         6.2.50.20020308-cvs        6.2.0.20020308-cvs
                 |                          |
         6.2.50.20020309-cvs        6.2.1 (update)
                 |                          |
         6.2.50.20020310-cvs         <branch closed>
                 |
         6.2.50.20020311-cvs
                 |
                 +--------------------------.
                 |                     <gdb_6_3-branch>
                 |                          |
         6.3.50.20020312-cvs        6.2.90 (draft #1)
                 |                          |

### 19.2 Release Branches

gdb draws a release series (6.2, 6.2.1, ...) from a single release branch, and identifies that branch using the cvs branch tags:

         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 (YYYY MM DD) in the tag. The branch tag, denoting the head of the branch, does not need this.

### 19.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)`’.

### 19.4 Experimental Branches

#### 19.4.1 Guidelines

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 mainline.
a branch shall contain the entire gdb module
  The gdb module `gdb` should 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., ‘`6.2.50.20030303_owner_name`’ or ‘`6.2 (Owner Name)`’.

#### 19.4.2 Tags

To simplify the identification of gdb branches, the following branch tagging convention is strongly recommended:

owner`_`name`-`YYYYMMDD`-branchpoint`
owner`_`name`-`YYYYMMDD`-branch`
  The branch point and corresponding branch tag. YYYYMMDD is the date that the branch was created. A branch is created using the sequence:

                cvs rtag owner_name-YYYYMMDD-branchpoint gdb
                cvs rtag -b -r owner_name-YYYYMMDD-branchpoint \
                   owner_name-YYYYMMDD-branch gdb

owner`_`name`-`yyyymmdd`-mergepoint`
  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.