From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Michael Elizabeth Chastain , GDB Discussion Subject: Re: CVS versions of gdb have same number as stable version. Date: Wed, 21 Mar 2001 15:59:00 -0000 Message-id: <3AA149E4.3B6AAFA8@cygnus.com> References: <200102161607.IAA23711@bosch.cygnus.com> X-SW-Source: 2001-03/msg00024.html 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