Change-Least Evolved Branch

Thu Jun 25 21:20:58 PDT 1998

John Mitchell writes:
> > I have two problems with this. First, lets use an example to help make
> > the discussion "concrete." Suppose I am using a "mainline" that is
> > currently beind used for features in the upcoming 2.0 release. Suppose
> > further that some short time back (say one month) a branched off a 1.x
> > codeline for all subsequent v1.0 releasing and maintenance (so it will
> > have work for v1.0, 1.1, 1.2, etc.):
> > 
> >                                    (more 1.0)    (1.1 and beyond)
> >                          1.X-line +-----------*-------------------->
> >                                  /
> >                                 /
> >   mainline --------------------*----------------------------------->
> >              (1.0 development)     (2.0 development, and beyond)
> 
> Ah, I think this may be the crux of the problem.  I.e., I think an
> important change to the underlying codeline model is in order. I think what
> you "really" want is something more like:
> 
> 		v1.0	v1.0.x	  v1.1	   v1.1.x    v2.0 (rel)
> 		 +-|-------|	    +-----|---|	       +-------
> 		/  |	   |	   /	  |  (a)      /
> 	       /   v	   v	  /	  v	     /
> mainline -----*----*--*----*-*-*-*--------*-----*---*----------
> 		       \     | ^		^    \
> 			\    v |	 (b)	|     \
> 			 +---*-*--*-------*-----|      +-------
> 			v2.0 (dev) \	  ^	     v3.0 (dev)
> 				    \	  |
> 				     +----*
> 				 v2.0 (johnm)
> 
> I.e., the mainline is truly just a main line from which everything
> branches.

Thats one possibility, but the way Chris and Laura describe it,
mainline is consistently used for the latest and greatest (LAG)
development; and you don't branch off of mainline until as late as
possible. So I don't branch off for release 2.0 at the very beginning, I
would wait until work for 2.0 actually needs to take place concurrently
with previous and/or subsequent releases.

However, none of that really changes my question IMHO.

> Laura's & Chris's rule of thumb is, IMVHO, addressing the issue where
> you have a change that you know has to eventually end up in multiple
> codelines.  I.e., it addresses the question of "where *should* you
> *introduce* such a change so that it is the easiest to deal with."

Yes - that is the same thing that I was talking about before (at least
I intended it to be). In the case of a fix to 1.0, you would know that
the fix must eventually make its way into both 1.1 and to any
subsequent release of 1.1 (including 2.0).

> So, in the above situation, I (johnm) decide to make a bunch of drastic
> changes to the 2.0 dev branch.

And here is the *crux* of the problem. Its not the stuff you talk about
later, its why you chose to modify 2.0 dev if you thought one or more
other branches were equally likely candidates. If you didn't think that
far ahead, okay - but then the "change least evolved" is no longer
applicable because you've already started the changes on that branch,
and its referring to the choice of what the branch should be. So I can
certainly understand the rest of the scenario you described, but I don't
believe it falls under the case we're talking about (for reasons previously
stated).

> Indeed, that's part of why I think your codeline model needed changing.

The model you drew was fine but it didn't really change anything IMHO
with regard to the question I was asking.

> We need to build from a model which most easily facillitates the
> realities of development. :-)

True - but theres nothing at all unrealistic about the model I drew. I
did deliberately omit transient branches that last only for the duration
of a single fix/enhancement (etc) because those aren't codelines as far
as I'm concerned (I don't consider a "branch" to be a codeline unless it
is more persistent, encompassing multiple logical changes (fixes/features)
instead of just one, even though it might have private checkpoints along
the way).

The diagram I drew was more streamlined than yours (with fewer
codelines), NOT because its somehow naive or simplistic/unrealistic,
but because it was deliberately designed that way using a combination
of the "mainline" and "branch late" strategies described in Chris and
Laura's paper. For example, when and if release 1.1 and release 2.0
efforts start taking place concurrently, *then* you need to branch off
for release 1.1 (and keep 2.0 on the mainline as LAG development,
assuming you haven't started 3.0 work yet). But before that time, you
actually do NOT have to create a 2.0 branch, even if you know you will
need it eventually. At least thats how I interpret the "Branch Late"
practice.

Regardless, even if you use a separate codeline for each and every
release (but still branch back to main eventually), I don't see how it
fundamentally changes the original question.

> Hell, think about the case where the v1.1 release branch is cascaded
> off the v1.0 branch or has to proceed in parallel to the v1.0.x branch

Frankly - I don't see how that changes anything. For any given fix/feature,
someone (often the project lead, but not always) has to decide which of
the currently "in-progress" set of releases (e.g. 1.0.1, 1.1.0, 1.1.1, 2.0,
etc.) should have the fix/feature. This is rarely decided by looking
at the branch topology (nor should it usually be decided that way). Its 
usually decided by looking at business reasons for which functionality
should go in which releases, and is often accompanied by advice on whats
technically feasible. Frequently, the deciding factor is schedule.

So once you know the earliest such release (which in this case would be
the lowest numbered one), then you typically will want/need it to
migrate to all successors of that release. At that point, there should
be one and only one publicly available codeline (not any old branch,
but a "codeline", using my earlier definition) for which work for that
release is taking place (again, this rules out consideration of singly
activity branches off the codeline, or other peoples private/personal
codelines branched off the codeline). This is the codeline where you make
the change, and it gets propagated, in release-number order, to all
subsequent codelines. I don't see why the question of "what is least
evolved" should ever be entering the picture when deciding which
codeline to originate the changes in.

So I'm still at a loss to understand this :-(
- -- 
Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/
 "And miles to go before I sleep."   |  3700+ WWW links on CS & Sw-Eng