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

[Chuck Karish]

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.

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

> 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

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