This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
6.3.50.2004-11-31 instead of 6.3.50_20041131; Was: Changes to snapshotdirectory
- From: Andrew Cagney <cagney at gnu dot org>
- To: gdb at sources dot redhat dot com
- Date: Wed, 01 Dec 2004 15:08:11 -0500
- Subject: 6.3.50.2004-11-31 instead of 6.3.50_20041131; Was: Changes to snapshotdirectory
- References: <4188F500.4060205@gnu.org>
Andrew Cagney wrote:
I'm looking to change GDB's snapshots/ directory. At present we've:
ftp://sources.redhat/com/pub/gdb/snapshots/branch/
ftp://sources.redhat/com/pub/gdb/snapshots/current/
where the first directory contains tarballs from the most recent branch,
and the latter tarballs from the mainline.
The problem I see with this is that it is hard to track a snapshot
series vis:
gdb-6.2.50 -> gdb-6.2.90 -> gdb-6.3 -> gdb-6.3.1
you need to ``just know'' that half is found in current/ and half is
found in branch/.
I can think of two alternatives:
- flatten things - snapshots/
- have separate release series directories - 6.2, 6.3, ...
I've a vague preference for the former,
thoughts?
In looking to implmement this I identified another simplification. I
think we can reduce things to:
6.2.90_2004-11-23 -> 6.2.90.20041123
6.3 -> 6.3
6.3.0.90_2004-11-25 -> 6.3.0.20041125
i.e., make the date just another part of the version number.
I've attached an attempt at revising the doco to reflect this.
comments?
Andrew
2004-12-01 Andrew Cagney <cagney@gnu.org>
* gdbint.texinfo (Versions and Branches): Make the date (YYYYMMDD)
part of the version number.
Index: gdbint.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v
retrieving revision 1.226
diff -p -c -r1.226 gdbint.texinfo
*** gdbint.texinfo 12 Oct 2004 19:14:31 -0000 1.226
--- gdbint.texinfo 1 Dec 2004 19:43:17 -0000
*************** configuration.
*** 5391,5419 ****
@table @asis
@item @var{major}.@var{minor}
@itemx @var{major}.@var{minor}.@var{patchlevel}
! an official release (e.g., 6.0 or 6.0.1)
! @item @var{major}.@var{minor}.@var{patchlevel}_@var{YYYY}@var{MM}@var{DD}
! a snapshot (e.g., 6.0.50_20020630)
! @item @var{major}.@var{minor}.@var{patchlevel}_@var{YYYY}-@var{MM}-@var{DD}-cvs
! a @sc{cvs} check out (e.g., 6.0.90_2004-02-30-cvs)
@item @var{major}.@var{minor}.@var{patchlevel}_@var{YYYY}@var{MM}@var{DD} (@var{vendor})
a vendor specific release of @value{GDBN}, that while based on@*
! @var{major}.@var{minor}.@var{patchlevel}_@var{YYYY}@var{MM}@var{DD},
! may contain additional changes
@end table
@value{GDBN}'s mainline uses the @var{major} and @var{minor} version
numbers from the most recent release branch, with a @var{patchlevel}
! of 50. As each new release branch is created, the mainline
! @var{major} and @var{minor} version numbers are accordingly updated.
! @value{GDBN}'s release branch uses a similar, but slightly more
! complicated scheme. When the branch is first cut, the mainline's
! @var{patchlevel} is changed to .90. As draft releases are drawn from
! the branch, the @var{patchlevel} is incremented. Once the first
! release (@var{major}.@var{minor}) has been made, the version prefix is
! updated to @var{major}.@var{minor}.0.90. Follow on releases have an
! incremented @var{patchlevel}.
If the previous @value{GDBN} version is 6.1 and the current version is
6.2, then, substituting 6 for @var{major} and 1 or 2 for @var{minor},
--- 5391,5435 ----
@table @asis
@item @var{major}.@var{minor}
@itemx @var{major}.@var{minor}.@var{patchlevel}
! an official release (e.g., 6.2 or 6.2.1)
! @item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD}
! a snapshot taken at @var{YYYY}-@var{MM}-@var{DD}-gmt (e.g.,
! 6.1.50.20020302,@* 6.1.90.20020304, or 6.1.0.20020308)
! @item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD}-cvs
! a @sc{cvs} check out drawn on @var{YYYY}-@var{MM}-@var{DD} (e.g.,
! 6.1.50.20020302-cvs,@* 6.1.90.20020304-cvs, or 6.1.0.20020308-cvs)
@item @var{major}.@var{minor}.@var{patchlevel}_@var{YYYY}@var{MM}@var{DD} (@var{vendor})
a vendor specific release of @value{GDBN}, that while based on@*
! @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD},
! may include additional changes
@end table
@value{GDBN}'s mainline uses the @var{major} and @var{minor} version
numbers from the most recent release branch, with a @var{patchlevel}
! of 50. At the time each new release branch is created, the mainline's
! @var{major} and @var{minor} version numbers are updated.
! @value{GDBN}'s release branch uses a similar. When the branch is cut,
! the @var{patchlevel} is changed from 50 to 90. As draft releases are
! drawn from the branch, the @var{patchlevel} is incremented. Once the
! first release (@var{major}.@var{minor}) has been made, the
! @var{patchlevel} is set to 0 and follow on update has an incremented
! @var{patchlevel}.
!
! For snapshots, and @sc{cvs} check outs, it is also possible to
! identify the @sc{cvs} origin:
!
! @table @asis
! @item @var{major}.@var{minor}.50.@var{YYYY}@var{MM}@var{DD}
! drawn from the @sc{head} of mainline @sc{cvs} (e.g., 6.1.50.20020302)
! @item @var{major}.@var{minor}.90.@var{YYYY}@var{MM}@var{DD}
! @itemx @var{major}.@var{minor}.91.@var{YYYY}@var{MM}@var{DD} @dots{}
! drawn from a release branch prior to the release (e.g.,
! 6.1.90.20020304)
! @item @var{major}.@var{minor}.0.@var{YYYY}@var{MM}@var{DD}
! @itemx @var{major}.@var{minor}.1.@var{YYYY}@var{MM}@var{DD} @dots{}
! drawn from a release branch after the release (e.g., 6.2.0.20020308)
! @end table
If the previous @value{GDBN} version is 6.1 and the current version is
6.2, then, substituting 6 for @var{major} and 1 or 2 for @var{minor},
*************** here's an illustration of a typical sequ
*** 5422,5455 ****
@smallexample
<HEAD>
|
! 6.1.50_2002-03-02-cvs
|
! +---------------------------.
| <gdb_6_2-branch>
- | |
- 6.2.50_2002-03-03-cvs 6.1.90 (draft #1)
- | |
- 6.2.50_2002-03-04-cvs 6.1.90_2002-03-04-cvs
- | |
- 6.2.50_2002-03-05-cvs 6.1.91 (draft #2)
- | |
- 6.2.50_2002-03-06-cvs 6.1.91_2002-03-06-cvs
- | |
- 6.2.50_2002-03-07-cvs 6.2 (release)
| |
! 6.2.50_2002-03-08-cvs 6.2.0.90_2002-03-08-cvs
| |
! 6.2.50_2002-03-09-cvs 6.2.1 (update)
! | |
! 6.2.50_2002-03-10-cvs <branch closed>
|
! 6.2.50_2002-03-11-cvs
|
! +---------------------------.
| <gdb_6_3-branch>
! | |
! 6.3.50_2002-03-12-cvs 6.2.90 (draft #1)
! | |
@end smallexample
@section Release Branches
--- 5438,5471 ----
@smallexample
<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)
! | |
@end smallexample
@section Release Branches
*************** branch (branches of individual files sho
*** 5525,5531 ****
@item a branch shall be branded using @file{version.in}
The file @file{gdb/version.in} shall be modified so that it identifies
the branch @var{owner} and branch @var{name}, e.g.,
! @samp{6.2.50_20030303_owner_name} or @samp{6.2 (Owner Name)}.
@end table
--- 5541,5547 ----
@item a branch shall be branded using @file{version.in}
The file @file{gdb/version.in} shall be modified so that it identifies
the branch @var{owner} and branch @var{name}, e.g.,
! @samp{6.2.50.20030303_owner_name} or @samp{6.2 (Owner Name)}.
@end table