Re: Not a CVS questions but a SW configuration question!

[James Youngman]

Annette Waters <address@hidden> writes:

> Sorry if this is not the place  to ask this but here goes: :<)
> 
> I am looking for a matrix or tree structure for release numbering schemes.
> i.e,
> three different products that have
> 1) developers version number
> 2) Configuration management build/release number
> 3) Marketing release number
> 
> Any and all help greatly appreciated!

I tend to handle this situation in a "cascade" manner.   

We have a "standard" for developers' tags on the trunk -- they take
the form "build_XXXX" and each tag is recorded elsewhere.  This
external record contains the module name, the tag name, the person
creating the tag and the reason they did it, for example

wholething build_0037 YoungmanJ "Fixed bug report 485302"

We have a separate release log which indicates what software was
released to who.   It contains the build_XXXX tag name.  Previous
projects have required various forms of output document to be
associated with a release.  I generally write a shell script to
generate this stuff.  

For example, one project required me to generate full or patch
releases (patch releases containing only the files changed since the
last release, which you can find out from "cvs rdiff -s").  There was
also a requirement to record the low-level revision number of each
file in the release (because the CM team was used to SCCS and couldn't
believe that a CVS release tag was "enough").

If the downstream users (CM, marketing) have a different name for a
build which we provide, we can just use 
"cvs rtag -rbuild_XXXX marketing_release_name wholething".

One nice-to-have would be to automate the capturing of log information
(e.g. the "why" of things) for our build tags.

-- 
James Youngman
Manchester, UK.  +44 161 226 7339
PGP (GPG) key ID for <address@hidden> is 64A95EE5 (F1B83152).