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

[Chuck Karish]

On 9/25/07, Rick Macdonald <rickmacd at shaw.ca> wrote:
> 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.

If the number of fixes being made and the number of service packs
yourelease are relatively small, you can release the service packs
from waypoints on the release/maintenance branch:


       1.0.1        1.1.1                2.0.1     2.1.1
        /            /                    /         /
 /-1.0----------1.1-----------     /-2.0-----2.1-------------
/                                 /
--main--------------------------------------------------------


Under this pattern I'd release service packs for use by new customers
and by feature-hungry customers and individual patches for risk-averse
customers.  For a point fix (patch) just the files involved in the
patch can be integrated into a tiny branch, then applied for testing
to the base against which they'd be delivered.  It's not necessary to
make a full branch for each patch.  Full-branch-per-patch actually makes
it harder to test patches in combination; it's much more efficient to
apply the patches you want to test to a common base.

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