This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

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


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.90(branch) -> 4.18.91 -> 5.0 ->
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
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- ....

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-, ...

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]