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

[Chuck Karish]

On 9/21/07, Brian Jones <caneridge at gmail.com> wrote:
> I'm working towards the second branching model you mention except that we
> are project focused, not version focused:

What's the reason for the project focus?  Do you deliver different
products to different customers?

> .   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.

I don't see a strong normative force in this strategy that pushes all these
projects to converge into a single code base.  What keeps people on different
project branches from making incompatible choices that can be released to
customers but which can't be shared with other projects?

  Chuck

-- 
Chuck Karish   karish at well.com   (415) 317-0182