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

[Rick Macdonald]

I've been creating Perforce branches as you show in your option #3 for 
almost 10 years now. I wouldn't give credit to Subversion or to me for 
this idea. It was just a natural thing to do. I confess, I've never made 
a label once in my life.

A "physical" branch is simple, easy, cheap, very visible in the depot 
(GUI) and on disk, with names that match, has a history that is easy to 
see, etc. Being a branch, you're not limited to a single changelist 
number if that doesn't fit the way you accumulate what goes into a 
release. Using ideas from Laura's book, which includes Jobs, you can 
script simple queries to show what fixes are in one release compared to 
any other (perhaps helping to automatic release notes), and on and on.

I'll be watching this thread to see if anybody thinks this is _not_ a 
good way to go!

...RickM...

Steve M. Robbins wrote:
> 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
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>