[p4] How do YOU identify the code set for a release?

[Steve M. Robbins]

Hi,

Suppose we're following the Mainline Model for development as
discussed, e.g., in Laura Wingerd's book.  We've created a branch for
the 1.X series of our code and we've stabilized along that branch to
the point that 1.1 is ready to package and ship.

What is a good strategy for identifying the code set that goes into
version 1.1?

Wingerd's book talks about using labels, but also says, roughly, "the
changelist number is good enough, you don't need a label".  

So option #1 is to use a label.  Coming from years of CVS use, this is
what I naturally gravitated to.  I was a little surprised that
creating a label is so cumbersome; e.g. it involves filling out a
form.  But I created a small script to turn it back into a one-liner
similar to what one does in CVS.

I know there are both 'static' and 'automatic' labels; let's assume we
would only ever care to release at a changelist, so we use only
automatic labels where the Revision: field is a changelist number.  My
script essentially takes the label string and a changelist number,
then creates and submits the appropriate form.

One downside of this approach that I've found is that p4v makes
working with labels fairly cumbersome: by default, you see labels
created by you.  My script actually creates them as a "build" user, so
you have to go and manually type in "build" each time to find the
labels.  And then you see *all* labels across the whole depot, which
is not as nice as "cvs stat -v Makefile" to find all the labels
associated with a given project in the depot.

Option #2 is to simply use the changelist.  You might just use the
changelist number as the revision number; e.g. call the software as
"1.1.323" if it's built using CL 323.  That leads to a simple rule
that maps the software version to a code set.  But some folks might
prefer to name releases 1.1.1, 1.1.2, 1.1.3, etc.  Then we need to
store a mapping from these numbers to the CL number somewhere.  In
addition, I don't know that p4v has any support to browse existing
releases; I could imagine a web application that would show them,
however (any suggestions?)

Option #3 is to use the subversion convention.  Recently, I've been
using subversion for more and more of my open source hobby work.  So
I've been exposed to the (standard?) subversion way of doing things
which is basically to create a branch for each released version.  Thus
there is a 1.x codestream branched from the main line, and then a
1.1.1 codestream branched from the 1.x stream.  A naming convention is
used to distinguish the kinds of branches.  Subversion uses something
like:

    ..../project
            /trunk     (main codestream)
            /branches
                /1.x   (1.x codestream)
                /2.x   (2.x codestream)
            /tags
                /1.1.1
                /1.2.0
                /2.2.1

Stabilization, for example, will be carried out in .../branches/1.x,
and then this is branched into ..../tags/1.1.1.  I believe that only
convention prevents one from integrating into /tags/1.1.1 more than
once.

This scheme begins to appeal to me more since it is "filesystem-like"
and thus the p4v browser gives you a way to browse revisions quite
directly.  


At this point, I'm interested to learn what others do.
Do you see other flaws or benefits to my 3 options?
Are there other options?

How do YOU identify the code set for a release?

Thanks,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://maillist.perforce.com/pipermail/perforce-user/attachments/20080103/19afabe4/attachment.bin