gdb's version is determined by the file gdb/version.in and takes one of the following forms:
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:
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> | 126.96.36.19920302-cvs | +--------------------------. | <gdb_6_2-branch> | | 188.8.131.5220303-cvs 6.1.90 (draft #1) | | 184.108.40.20620304-cvs 220.127.116.1120304-cvs | | 18.104.22.16820305-cvs 6.1.91 (draft #2) | | 22.214.171.12420306-cvs 126.96.36.19920306-cvs | | 188.8.131.5220307-cvs 6.2 (release) | | 184.108.40.20620308-cvs 220.127.116.1120308-cvs | | 18.104.22.16820309-cvs 6.2.1 (update) | | 22.214.171.12420310-cvs <branch closed> | 126.96.36.19920311-cvs | +--------------------------. | <gdb_6_3-branch> | | 188.8.131.5220312-cvs 6.2.90 (draft #1) | |
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 (YYYYMMDD) in the tag. The branch tag, denoting the head of the branch, does not need this.
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)’.
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:
gdbshould be specified when creating a branch (branches of individual files should be avoided). See Tags.
To simplify the identification of gdb branches, the following branch tagging convention is strongly recommended:
cvs rtag owner_name-YYYYMMDD-branchpoint gdb cvs rtag -b -r owner_name-YYYYMMDD-branchpoint \ owner_name-YYYYMMDD-branch gdb
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.