From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13555 invoked by alias); 7 Mar 2002 02:11:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13496 invoked from network); 7 Mar 2002 02:11:28 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 7 Mar 2002 02:11:28 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 06E6C3D1D for ; Wed, 6 Mar 2002 21:11:26 -0500 (EST) Message-ID: <3C86CC4E.6050801@cygnus.com> Date: Wed, 06 Mar 2002 18:11:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: ["patch"/doc] GDB version and branch names Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00088.txt.bz2 Hello, below is an attemt at documenting the GDB branch and version policies. Comments wanted. If you think the rationale for something is unclear, please point it out. enjoy, Andrew @section Version and branch names @subsection Versions @value{GDBN}'s version is determined by the file @file{gdb/version.in}. @value{GDBN} never uses letters in its version identifier, letters being reserved for vendor customised @value{GDBN} releases. Conversely, a vendor customised @value{GDBN} release is expected to modify the version identifier so that it includes letters (and digits). @value{GDBN}'s mainline uses only dates to differentiate between versions. The CVS repository uses @file{YYYY-MM-DD-cvs} while corresponding snapshots use @file{YYYYMMDD}. To avoid confusion between the main-line, @value{GDBN}'s release branches use a more complex version naming scheme. The schema assumes that a series of releases, starting with a major.minor and possibly followed by a number of major.minor.minor releases are all to be drawn from a single branch. When a release branch is first cut, the version identifier is updated to include a prefix constructed from the previous release serieuses major.minor (@file{m.n}) identification with a @file{.90} suffix appended. Consequently, CVS versions are identified with @file{m.n.90-YYYY-MM-DD-cvs} and snapshots are identified with @file{m.n.90_YYYYMMDD}. As draft releases are drawn from the branch, the minor minor number (@file{.90}) is incremented. Once an official release (@file{M.N}) has been made, the version identifier is updated to contain @file{M.N.0.90} (dot zero, dot ninety) as the prefix. Consequently, @file{M.N.0.90-YYYY-MM-DD-cvs} identifies CVS versions while @file{M.N.0.90_YYYYMMDD} identifies a snapshot. Succeeding releases increment the minor minor number (@file{.0} or dot zero). Succeeding draft release candidates increment the minor minor minor number (@file{.90}). Since @value{GDBN} no longer makes minor minor minor releases (e@.g@. @file{5.1.0.1}), there is no potential version number conflict. The following a example illustrates this sequence using @file{5.1} as the previous (@file{m.n}) release series and @file{5.2} @file{M.N} as the current release series. @example 5.1.90-YYYY-MM-DD-cvs 5.1.91 (draft release candidate) 5.1.91-YYYY-MM-DD-cvs 5.1.92 (draft release candidate) 5.1.92-YYYY-MM-DD-cvs 5.1.93 (a lie, really 5.2) 5.2 (release) 5.2.0.90-YYYY-MM-DD-cvs 5.2.1 (release) 5.2.1.90-YYYY-MM-DD-cvs @end example @itemize @bullet @item Minor minor minor draft release candidates such as @file{5.2.0.91) were intentionally omitted from the example, such release candidates will most likely never be made. @item @file{5.1.93} is described as @emph{a lie} since the bziped tar ball @file{gdb-5.1.93.tar.bz2} is just the @file{gdb-5.2.tar} file renamed an compressed. @end itemize @subsection Branches Releases 5.0 and 5.2 used branch tags of the form: @example gdb_N_M-YYYY-MM-DD-branchpoint gdb_N_M-YYYY-MM-DD-branch gdb_M_N-YYYY-MM-DD-release @end example Release 5.2 is trying out: @example gdb_N_M-YYYY-MM-DD-branchpoint gdb_N_M-branch gdb_M_N-YYYY-MM-DD-release @end example @emph{Pragmatics: The branchpoint and release tags need to identify when a branch and release are made. The branch tag, denoting the head of the branch, does not have this criteria.}