Re: CVS versions of gdb have same number as stable version.

Andrew Cagney
2001-03-21T15:59:00Z

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
separate file.

Please don't ask which
file, I neither know nor
care :-)

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
savings :-)

What the wack does is
discused below.

Pratmatics:

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 -> 4.18.0.90 -> 4.18.90(branch) -> 4.18.91 -> 5.0 -> 5.0.0.90
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
applied.

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
suggest:

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
over kill.

Looking at the likely 5.1 senario:

trunk: gdb-5.0-20030229
5.1 branch: gdb-5.0.90, gdb-5.0.91, ...

(Strictly speaking) when 5.1 was released things would follow:

trunk: gdb-5.1-20042301
5.1 branch: ...gdb-5.0.99, gdb-5.1 frozen
5.1.1 branch: gdb-5.1.0.90 ....

However, being essentially lazy, I'd actually do:

trunk: gdb-5.1-20054705
5.1 branch: gdb-5.0.99, gdb-5.1 (tag), gdb-5.1.0.90, ...

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?

Andrew