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

[Rick Macdonald]

Thanks for taking the time to describe this. I really appreciate it.

My comments are directed to how this would succeed or fail in my shop, 
not yours.

One detail that makes this workable for you but not me is that you are 
able to stop P1 when P2 starts. We don't have that luxury, at least not 
for stabilizing (bugfix changes). We must fix a bug in 1.0.3 to create 
1.0.4 even when most the company is using 2.1.4.

I'm replacing a horrible, horrible system that's biggest feature is that 
the tools and procedures used at any one time for any given task depends 
entirely on what other activity is active at the same time, what 
activity has recently been started or completed and not merged, etc. The 
rules are full of "if this and that" and "when this and that" and 
"before" or "after", etc. The result is that one can't start a new task, 
large or small, without talking to some number of arbitrary people. When 
your work is complete, to get your changes back into the parent 
codeline, you have to again do the research to figure out what to do. 
And, the list of people you may have to search out will not necessarily 
be the same as when you started. Of course, some number of programmers 
in the wild ignore all that and just grab some version of the code to 
make their changes to, don't know how or where to integrate their 
changes, and the whole thing dissolves.

I'm afraid I see a lot of "if" and "when" in your procedures. The only 
"if" that I can think of in our scenario is "if you do work in the 1.x 
release stabilization branch (as opposed to doing it off the mainline), 
you also have to integrate it to the mainline when you're done". We too 
have a script (integrated as a p4v custom tool) to automate steps and 
make things simpler. A good example is Laura's "copy up" recipe. But the 
script itself doesn't have to make any decisions about source and target.

...RickM...

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