[p4] Branching strategy for major.minor.patch versioning
Rick Macdonald
rickmacd at shaw.ca
Mon Sep 24 23:14:13 PDT 2007
Brian,
I think your project focus vs our version focus does make a difference.
We don't have anybody influencing our version numbers. Also, these are
relatively small and independent libraries (but hundreds of them) that
are numbered individually. Our old system assigned version numbers
before work started, which is hopeless. The new system will not assign
numbers until released. I plan to name our development branches the same
as the test version name, which includes the bug report number for
reference prefixed by an indication of the parent version (either a
version number or the mainline).
Rick
Brian Jones wrote:
> Rick,
>
> In our environment, the project branches live in parallel. It's just too
> hard to represent that in a character graphic, so I left it out. I've had
> multiple release branches merging into multiple project branches all at the
> same time, although that was under ClearCase. The same business practices
> are in place where I work now so the same parallelism will be in play with
> our perforce branching.
>
> I agree with you that the fewer rules the better. I think that most of the
> rules I spoke of were not things developers had to know but rather something
> the build/branch team manages. Developers just need to know which product
> needs their change and to check all down stream products for build failures
> after they deliver code, so the branch protocol from a developer perspective
> is very simple (I think).
>
> Does your find that your target version numbers get changed by marketing or
> higher level business decisions often? If you are targeting V2.1.0 for
> example, what will you do if management wants that to be release V3.0? This
> gets into the notion of early vs. late binding on version numbers with your
> branch naming convention. I'm opting for using code names for branches to
> avoid the problem altogether.
>
> Brian
>
> On 9/24/07, Rick Macdonald <rickmacd at shaw.ca> wrote:
>
>> 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
>>>
>>>
>>>
>>
> _______________________________________________
> perforce-user mailing list - perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>
More information about the perforce-user
mailing list