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

[Rick Macdonald]

Chuck Karish wrote:
> On 9/20/07, Rick Macdonald <rickmacd at shaw.ca> wrote:
>   
>> My natural thought for major.minor.patch is that each major release
>> needs it's own accumulation branch, with a release stabilization branch
>> for each minor version. My interpretation is that this is what Laura has
>> in her book as well (Chapter 7, pages 183-185). I've drawn the actual
>> releases (1.0.0, 1.0.2, etc) as branches because that's what I do for
>> convenient automated builds, but they could be labels or just changelist
>> numbers. Regardless, they are to be considered snapshots and never
>> actually updated once released.
>>
>>      1.0.0   1.0.1    1.1.0            2.0.0       2.1.0
>>     /       /        /                /           /
>>    /-1.0-------     /-1.1----        /-2.0----   /-2.1------
>>   /                /                /           /
>>  /-1--------------------------     /-2-----------------------
>> /                                 /
>> --main--------------------------------------------------------
>>
>>
>> A bugfix done to the 1.0 stabilization branch to release 1.0.2 would
>> have these integrations if everybody needed the same bugfix:
>> -1.0 to 1
>> -1 to 1.1 to release 1.1.1
>> -1 to main
>> -main to 2 (or 1 to 2?)
>> -2 to 2.0 to release 2.0.1
>> -2 to 2.1 to release 2.1.1
>>     
>
> If you have to release new features on existing releases you
> need the extra set of branches to maintain those features.
> It's a big win to convince your project managers that existing
> releases should get only bug fixes.
>   
Good point. That's actually how I've pitched it in the past. If we do 
that, doesn't that imply that a 2-node version is adequate? (see next 
paragraph)

My original email was asking about 3 version nodes with and without the 
"1" branch as the parent of 1.1, 1.2, etc. Now that we've established 
that the first diagram (with the proper parent branch) is the way to go, 
do you have any comments on what I actually prefer, which is a 2-node 
version system? This means using the minor node only for bugfixes, or 
perhaps allowing "low-risk" changes such as simple new features. We'd 
use the major version node for higher risk changes. This is a 
compromise, of course, with the upside being fewer integrations. I think 
binary incompatibility is rare for us, so I figure we wouldn't miss the 
extra distinction of the first node of a 3-node scenario very often, not 
compared to having to live daily with extra integrations.

>> I've had the following suggestion, which is that the minor version
>> accumulation can be in the mainline:
>>
>>    1.0.0  1.0.1      1.1.0         2.0.0        2.1.0
>>   /      /          /             /            /
>>  /-1.0---------    /-1.1----     /-2.0----    /-2.1
>> /                 /             /            /
>> --main--------------------------------------------------------
>>
>>
>> A bugfix done to the 1.0 stabilization branch to release 1.0.2 would
>> have these integrations:
>> -1.0 main
>> -main to 1.1 to release 1.1.1 (or 1.0 to 1.1?)
>> -main to 2.0 to release 2.0.1 (or 1.1 to 2.0?)
>> -main to 2.1 to release 2.1.1 (or 2.0 to 2.1?)
>>     
>
> This is fine as long as there's never going to be a release 3.0.
> How would you separate changes meant for 3.0 from changes
> meant for 2.1?
>   
Yes, indeed.

>> Fewer integrations to get the same additional 3 releases. But is it a
>> reasonable thing to do? The problem that I have is when adding a new
>> feature (new minor version) to the major version 1. The only place where
>> the accumulated code _maybe_ exists for major version 1 is at the head
>> of the 1.1 branch. I say _maybe_, because if 1.1 was created before the
>> 1.0 bugfix 1.0.1, there is no policy that says the 1.0.1 fix had to be
>> integrated to 1.1 to release 1.1.1. We're trying to wean people off
>> these old versions, after all.  Still, one could create 1.2 from 1.1,
>> and integrate it to the mainline. Similarly, one could create 2.2 from
>> 2.01 and then merge the new feature into it from main (or from 1.2?). My
>> take on this is that it's not reasonable to create 1.2.0 with a new
>> feature knowingly leaving out previous bug fixes.
>>     
>
> Unless, of course, your customers don't mind that they see
> regressions or that they don't get all bug fixes.
>
>   
>> Is anything like this feasible to reduce integrating changes through so
>> many branches? Due to the promise of a stable production environment and
>> consistent results, we have to support any release used in production
>> for some time (could be measured in years).
>>     
>
> I think you've answered your question.  You need the full generality of the
> system in your first diagram.  You can minimize integration by reducing
> the number of features that are delivered to old release versions and by
> making branches as late as possible.
>
>   Chuck
>
>