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

[Shawn Hladky]

I suggest using a combination of all 3 options, depending on the support
level you need to provide for a particular build.

Option 2 is the common denominator for all 3.  If you have a changelist
number you can retroactively create an automatic label or a branch from the
original build.  So I suggest you implement the changelist approach for
every build.  There are many ways to associate this change number to a
build... see the recent thread on this mailing list "Changelist number in
versions".

Option 1 (assuming automatic labels) is nothing more than a user-friendly
alias to the changelist number.  People understand the concept "1.1.3"
better than change 15639.  If you create an automatic label named 'rel-1.1.3'
with the Revision field set to 15639, then the two revision specifiers "@
rel1.1.3" and "@15639" are the same point-in-time.  The automatic label can
also point you to the correct branch (using an explicit label view)... which
a changelist does not necessarily give you.  One word of advice, make sure
you use a consistent naming convention for these labels.  You may decide to
use labels for other things, and you don't want to confuse labels used for
builds with labels used for other purposes.

Option 3 provides the highest level of support for a release.  Obviously, if
you need to make a singular, specific change to a build, you need to have a
branch for that build (or you need to cherry-pick... that's another
conversation).  But sometimes you may want a branch even if you never need
to patch that particular build.  For example a developer may want to run
code through a debugger to troubleshoot a maintenance issue, but she doesn't
want to sync to a label and mess up her local changes for the latest
release.  There are other ways she could accomplish that, but a branch may
end up being the best way to support it in your process.

So, here's a hypothetical approach given a typical process.

* Daily builds always get a changelist number.  It can be as simple as a
version.txt file (containing the changelist) that ships with the binaries,
and still be effective.
* When a daily build is promoted to QA, create the automatic label using the
daily builds change number (ex rel-1.1).  You can even use two labels (
rel-1.1 is always the latest QA release, and rel-1.1.15639 is the specific
iteration to QA).
* When a major release is shipped, create the branch with 'p4 integ
//depot/trunk/... at rel-1.1 //depot/branch/rel-1.1/...'
* When you need to patch
--  Code in //depot/branch/rel-1.1/...
--  Build, create label rel-1.1.1 (and optionally rel-1.1.17359)

No matter what, you can always reproduce and maintain any build.  For
example, if a customer is on 1.1 and needs a hot-fix (but refuses to upgrade
to 1.1.1), you can create a new  branch with 'p4 integ //depot/trunk/...@
rel-1.1 //depot/branch/rel-1.1.PITA/...'  and code the hot-fix.

You can easily morph this to whatever versioning scheme and release process
in place at your company.


On Jan 3, 2008 4:31 PM, Steve M. Robbins <steve at sumost.ca> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHfXBb0i2bPSHbMcURAoW4AKCstEjHur3TNm4PeEcAAISiSMTrfQCfdfGs
> QlCLRa899OHtdPCZAnY5NJQ=
> =/pJk
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>