Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi,
At the moment I do something like this and have done so for about a year
with some success.
I have a sysid.h file that I manually control and edit to denote the
state of the baseline. The process may look like it needs some
automation but the amount of time it takes is minimal and I haven't felt
the need.
Whenever a new "official" release is made or I enter a Development phase
"dev" or a prerelease/feature freeze phase "pre" I edit this file and
commit it. I can then look at a revision "Graph" of this file to get a
feel for the baseline/branching history of the product.
So the sysid.h file contains something like this
<sysid.h>
#define BLAH_MAJOR 4
#define BLAH_MINOR 3
#define BLAH_REVISION 1
#define BLAH_MODE "_dev"
<sysid.h>
Then somewhere in "main.c" I report the version of the product I am
controlling using the cutomary -v flag.
<main.c>
#include "sysid.h"
void show_version(void)
{
printf( Version : %d.%2dr%d%s\n",
BLAH_MAJOR, BLAH_MAJOR, BLAH_MAJOR, %mode );
printf( BuildDate : %s %s\n",
__DATE__, __TIME__ );
return;
}
<main.c>
Before I create a tag for release I first enter a pre-release/feature
freeze phase where all bugs registered in Bugzilla for the upcoming
release's target milestone are tested and independantly verified. In
this example the target milestone would be "v4.03r1" and the version
reported would be "v4.03r1_pre". People verifying the bugs include how
they tested the bug together with the version and BuildDate. Any issues
found are resolved and committed and a complete rebuild is made. A new
build date is then available for subsequent testing.
When an Official Release is to be made I change the sysid.h file to
produce v4.03r1. And do a full rebuild and commit the executable to the
respository.
I also tag the source at this point using the following convention.
csci_reverseSortableDate_sortableVersion_reason
ie blah_2004_12_06_v4_03_r1_release
I also create a branch at this point called
blah_2004_12_06_v4_03_rX_branch
I then add a new target milestone to bugzilla v4.03r2.
I change my sysid.h file on the HEAD to produce v4.04r1_dev and commit it.
When I inevitably start work on v4.03r2 to fix post_release bugs or
introduce or backport features to customers who dont want the risk or
hassles of taking the latest version I update to the
blah_2004_12_06_v4_03_rX_branch and change the sysid.h file to produce
v4.03r2_dev. Development continues until v4.03r2_pre and finall v4.03r2
at which point i create a tag called
blah_2005_01_12_v4_03_r2_release.
If i need to do some potentially risky or intrusive development, I do it
on a branch and use the BLAH_MODE string to keep tabs on what the branch
is for. ie The branch would be called something like
blah_2004_12_14_v4_04_r1_Isolated_experiment_branch.
Cheers
Mikew
Adrian Crossley wrote:
> Hi
>
> We are about to migrate to CVS.
> We want to adopt the develop on trunk, tag for releases, branch from tags for post-release bugs method of using it.
> Can someone point me to a good convention for naming the tags and branches please?
>
> thanks in advance
> Adrian Crossley
> _______________________________________________
> cvsnt mailing list
> cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs