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

[Andrew Cagney <ac131313 at cygnus dot 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
		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