This is the mail archive of the
mailing list for the GDB project.
Re: CVS versions of gdb have same number as stable version.
- To: Michael Elizabeth Chastain <chastain at cygnus dot com>, GDB Discussion <gdb at sources dot redhat dot com>
- Subject: Re: CVS versions of gdb have same number as stable version.
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Sat, 03 Mar 2001 14:45:40 -0500
- References: <200102161607.IAA23711@bosch.cygnus.com>
Hmm, this turned out to be a hot topic, sorry ... :-)
First the easy bit:
Given that there doesn't appear to be any way of wacking
Makefile.in:VERSION during a CVS ci/co, I'd like to adapt CGF's
suggestion into the following:
o shove VERSION into a
Please don't ask which
file, I neither know nor
o add cronjobs to wack
that file daily.
The wack would occure
at about 00:00GMT.
An alternative might be
00:00 FJT but I suspect
GMT/UCT is best.
Who ever sets this up had
better remember daylight
What the wack does is
By putting version into its own little (very booring) file all the dummy
CVS commits are isolated.
The current snapshots are created at about 02:00GMT using 00:00 GMT as
the -D parameter. In theory, the hack that wacks the snapshot's VERSION
becomes redundant. In reality, I bet there is a race condition so that
hack should continue :-)
Now the more interesting bit:
Back in the good old days of ``open development'', everything was made
available using snapshots (GDB, BINUTILS, GCC all did this). During the
release cycle, the snaps would follow the branch and not the trunk vis
trunk -> trunk .-> warp-to-trunk
`-> branch -> release
Since the general public only saw the above flow, problems like
differentiating between trunks and branches didn't occure. A convention
like 4.18 -> 18.104.22.168 -> 4.18.90(branch) -> 4.18.91 -> 5.0 -> 22.214.171.124
made pretty good sense.
With CVS however, things are very different. I don't think that the
above model still applies. The flow is now:
.-> branch -> release (YYYYMMDD-bigted-1.2.3)
trunk -> trunk -> trunk -> trunk -> trunk -> trunk
`-> branch -> release 5.1
`-> branch -> release 5.1.1
`-> release 5.1.1-littleted-123
(and you thought life was easy :-) The trunk and the branchs are all
active at the same time. Patches are constantly, and randomly, been
With that in mind my first thought was:
trunk: gdb-YYYYMMDD (gdb-20010229)
branch: gdb-B.B.B-YYYY-MM-DD (gdb-5.0.90-20010229)
However, I've been ``educated'' by marketing :-) People like to know
the last release that a snapshot is based on. With that in mind could I
trunk: gdb-R.R.R-YYYYMMDD (gdb-5.0-20010229)
branch: gdb-R.R.R.BB (gdb-5.0.90, ....)
Where ``R.R.R'' is the last official release. When ever a release is
made, the trunk is updated to reflect this.
The trunk would be date stamped daily.
A branch could also get a daily date stamp but, well, I suspect that is
Looking at the likely 5.1 senario:
5.1 branch: gdb-5.0.90, gdb-5.0.91, ...
(Strictly speaking) when 5.1 was released things would follow:
5.1 branch: ...gdb-5.0.99, gdb-5.1 frozen
5.1.1 branch: gdb-126.96.36.199 ....
However, being essentially lazy, I'd actually do:
5.1 branch: gdb-5.0.99, gdb-5.1 (tag), gdb-188.8.131.52, ...
Oh, if you work this through, there is a small window during which both
the trunk and the branch could produce the version number
gdb-5.1-YYYYMMDD. I'll try to remember to not make the release during
00:00 GMT :-)
So again, to restart this discussion .... :-) Comments?