[p4] Branching strategy for major.minor.patch versioning

[Brian Jones]

Rick,

I'm working to install a very similar process where I work as well. I think
the key to making branches work, regardless of how you do it, is to create a
branching culture within the development community where tools and people
follows the same branching protocol. In a way, that is the real message in
the Perforce book, for me anyway.

I'm working towards the second branching model you mention except that we
are project focused, not version focused:

.   1.0.0  1.0.1      1.1.0         2.0.0        2.1.0
.  /      /          /             /            /        .
. /-1.0---------    /-1.1----     /-2.0----    /-2.1     .
./                 /             /            /          .
.--main--------------------------------------------------------

For us, the n.0 branches are project branches. These have a project manager
and drive to one or more releases, some of which may be concurrent, so
1.0.0could be developed at the same time as
1.1.0 and 1.0 could be developed at the same time as 1.1 for some period of
time. I think the real key here lines in how merging is done. I'm proposing
the following for my organization:

* No one works on main
* Forward work takes place on the tip of project branches
* Drive to completion work takes place on release branches
* Work is delivered to older code and is merged to newer code
* New code is not merged to older code (unless a special case arises)

With these automated merges
* 1.0.0 to 1.0.1 (if program appropriate)
* 1.0.1 to 1.0 (assuming there will be a 1.0.2 release)
* 1.0 to 1.1 (probably stopped before 1.1.0 is created)
...etc
* 2.1 merges without conflict to main

Our branching diagram will look more like this (R11 = your 1.0.0), the
numbers don't really matter that much here:

.       R11     R12       R21  R22   .
.      /      /           /   /      .
. /-P1 ------X   /-P2 --------       .
./     \\\\\\\\ / \\\\\\\\\\\\\      .
.--main------------------------            .

X means project stops development
\ is a merge back to base branch

For us it will work like this:

* Project P1 starts on their own project branch (your 1.0)
* They work and auto merge to main
* When R11 starts, R11 merges to P1
* When R12 starts, R11 may merge to R12 if R12 wants those changes
* R12 merges to P1 if there will be a R13 or to P2 if it is the last release
* Work on P1 stops when there are no more releases to make
* P2 can start at any time (due to the auto merges to main)
* When P2 starts, P1 to main merges are redirected: P1 to P2 and P2 then
merges to main

There are some ethics questions here such as:
* Should R12 merge to P1 even though no future releases are planned? Doing
this would allow management to start a R13 in the future without setup
costs. It also means that only P1 would merge to P2. Release branches never
merge across project boundaries.
* It might help to have a perforce trigger to turn off checkin for branches
where development has stopped. This helps stop some accidents from
happening.

I spent about 2 months writing an object oriented auto merge script for
Perforce. I'm not sure what I would do if I had to depend on developers
doing all the merges. I'd have to give that some thought. I also plan to do
continuous integration builds on all branches where there is active
development. These builds will include the automated merges when required
and will generate a build failure when merge conflicts occur.

Brian Jones