From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2192 invoked by alias); 17 Mar 2002 15:11:43 -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 1485 invoked from network); 17 Mar 2002 15:11:27 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 17 Mar 2002 15:11:27 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CBC263EC1; Sun, 17 Mar 2002 10:11:24 -0500 (EST) Message-ID: <3C94B21C.9000502@cygnus.com> Date: Sun, 17 Mar 2002 07: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: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/doc] Versions and Branches References: <3C919ABC.7000902@cygnus.com> <2947-Fri15Mar2002105949+0200-eliz@is.elta.co.il> <3C922442.5020102@cygnus.com> <9743-Fri15Mar2002205047+0200-eliz@is.elta.co.il> Content-Type: multipart/mixed; boundary="------------050209080702030007020906" X-SW-Source: 2002-03/txt/msg00276.txt.bz2 This is a multi-part message in MIME format. --------------050209080702030007020906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 627 > Date: Fri, 15 Mar 2002 11:41:38 -0500 >> From: Andrew Cagney >> >> So that I know I've got this straight: >> >> @var{.0} -> .0 >> @var{M.N.0.90} -> @var{M}.@var{N}.0.90 > > > Yes. Sorry I didn't make this clear earlier. > > >> BTW, are there any guidelines available online for this? > > > The Texinfo manual should be it. In Info, type "i var RET", and you > will be reading the explanations. If you think there's something > missing there (more examples?, please send a bug report to > bug-texinfo@gnu.org. Time to curl up and read the manual from end to end. Try the attached. Andrew --------------050209080702030007020906 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 3900 2002-03-15 Andrew Cagney * gdbint.texinfo (Releasing GDB): Add section ``Version identifiers'' and Branch Names'' Index: gdbint.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v retrieving revision 1.67 diff -u -r1.67 gdbint.texinfo --- gdbint.texinfo 2002/03/04 20:38:10 1.67 +++ gdbint.texinfo 2002/03/17 15:04:08 @@ -4822,6 +4822,105 @@ @chapter Releasing @value{GDBN} @cindex making a new release of gdb +@section Versions and Branches + +@subsection Version Identifiers + +@value{GDBN}'s version is determined by the file @file{gdb/version.in}. + +@value{GDBN}'s mainline uses ISO dates to differentiate between +versions. The CVS repository uses @var{YYYY}-@var{MM}-@var{DD}-cvs +while the corresponding snapshot uses @var{YYYYMMDD}. + +@value{GDBN}'s release branch uses a slightly more complicated scheme. +When the branch is first cut, the mainline version identifier is +prefixed with the @var{major}.@var{minor} from of the previous release +series but with .90 appended. As draft releases are drawn from the +branch, the minor minor number (.90) is incremented. Once the first +release (@var{M}.@var{N}) has been made, the version prefix is updated +to @var{M}.@var{N}.0.90 (dot zero, dot ninety). Follow on releases have +an incremented minor minor version number (.0). + +Using 5.1 (previous) and 5.2 (current), the example below illustrates a +typical sequence of version identifiers: + +@table @asis +@item 5.1.1 +final release from previous branch +@item 2002-03-03-cvs +main-line the day the branch is cut +@item 5.1.90-2002-03-03-cvs +corresponding branch version +@item 5.1.91 +first draft release candidate +@item 5.1.91-2002-03-17-cvs +updated branch version +@item 5.1.92 +second draft release candidate +@item 5.1.92-2002-03-31-cvs +updated branch version +@item 5.1.93 +final release candidate (see below) +@item 5.2 +official release +@item 5.2.0.90-2002-04-07-cvs +updated CVS branch version +@item 5.2.1 +second official release +@end table + +Notes: + +@itemize @bullet +@item +Minor minor minor draft release candidates such as 5.2.0.91 have been +omitted from the example. Such release candidates are, typically, never +made. +@item +For 5.1.93 the bziped tar ball @file{gdb-5.1.93.tar.bz2} is just the +official @file{gdb-5.2.tar} renamed and compressed. +@end itemize + +To avoid version conflicts, vendors are expected to modify the file +@file{gdb/version.in} to include a vendor unique alphabetic identifier +(an official @value{GDBN} release never uses alphabetic characters in +its version identifer). + +Since @value{GDBN} does not make minor minor minor releases (e.g., +5.1.0.1) the conflict between that and a minor minor draft release +identifier (e.g., 5.1.0.90) is avoided. + + +@subsection Branches + +@value{GDBN} draws a release series (5.2, 5.2.1, @dots{}) from a single +release branch (gdb_5_2-branch). Since minor minor minor releases +(5.1.0.1) are not made, the need to branch the release branch is avoided +(it also turns out that the effort required for such a a branch and +release is significantly greater than the effort needed to create a new +release from the head of the release branch). + +Releases 5.0 and 5.1 used branch and release 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 @var{5.2} is trialing the branch and release tags: + +@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.} + + @section Obsolete any code Before anything else, poke the other developers (and around the source --------------050209080702030007020906--