[p4] Question on Development, Main branches

[Rick Macdonald]

Chance Meek wrote:
> Currently, we have a development codeline, and we branch that codeline into
> release codelines.  From reading Practical Perforce and other White Papers,
> it seems that people recommend having a development codeline in addition to
> the mainline, as well as the release branches.
>   

This is what we do, but I'd call ours "development branches", not "a 
development codeline". See below...

> What may make sense for our group is to keep our development codeline as is,
> but then branch changes into a "stable" codeline, then promote those changes
> to a release codeline.  That way people can check in their work into the
> development codeline but not promote it to the "stable" codeline until it is
> finished to some degree.  We also have a small software group, about 9
> accounts.
>   
I've never needed anything like this, although I may be misinterpreting 
this idea due to the terminology.

> I'm curious what other people do, do you have a development codeline in
> addition to the main one?  Do you branch the development codeline into the
> main, or vice versa?  Do you branch the entire codeline or just selected
> modules?
>   

 From the mainline, we make individual private task-based "development 
branches" from the mainline. These branches are managed in the "Merge 
Down / Copy Up" fashion with the parent mainline.  From time-to-time, 
new releases are branched from the mainline into "release stabilization 
branches". From these branches, labels or branches are created for 
building actual releases (v1.00). Bugfixes and stabilizing changes are 
made in the release stabilization branches, leading to new minor version 
releases (v1.01, v1.02, etc). Major development work (new features, etc) 
with more risk are made in development branches off the mainline, 
integrated to the mainline when complete, and eventually lead to new 
major version releases (v3.xx, v4.xx, etc) with their own release 
stabilization branches. Bugfixes in the release stabilization branches 
are of course integrated to the mainline. This all assumes that we have 
to support previous major release versions even after new major versions 
are released. This is true for most but not all of our packages and 
applications. When such support is not required, we have only a mainline 
and development branches, and releases are made directly from the mainline.

In all cases, the policy of the mainline is that it must compile and run 
correctly and in essence be considered as viable as a release candidate 
at all times.

I believe all this is right out of Laura's book, or at least my 
interpretation!

Rick