Version 4 by Gavin
on Nov 22, 2006 13:36.

compared with
Current by Matthew Ratzloff
on Dec 06, 2006 23:19.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (18)

View Page History
A few people have asked, so let me explain our release model from a SVN perspective.
<h1>Branching Model</h1>

A basic mantra to keep in mind is: "_We work on branches and deploy from tags_"
<p>To best understand our release model from the point of view of Subversion, keep this in mind: &quot;We work on branches and deploy from tags.&quot;</p>

h3. So what does this mean?
<p>What is a branch? A branch is a fork of code that can change independently from other branches. A tag, on the other hand, is a point-in-time marker (as we use them) for a branch that signifies a consistent set of code. We mostly work on the &quot;trunk&quot; branch for all development and take a slight slowdown each milestone (i.e., &quot;release&quot;) to get a reasonable set of code to set for release. When we think we are ready, we create the release branch with the intention that it is unlikely to change. And if it does change, we want that to be tightly controlled and very well checked. The benefit of branching for the purpose of a release is that we can then continue to work on the trunk without fear of hurting the release. In fact, changes intended for the release after branching are first applied to the branch and <em>then</em> merged down to the trunk, either as they come in or when the release is ready, by doing them all en-masse. </p>

Well, a branch is a fork of code that can change independently from other branches. A tag is a point-in-time marker (as I use them) for a branch that signifies a consistent set of code. So, we mostly work on the "trunk" branch for all development and take a slight slow down each milestone (i.e. "release") to get a reasonable set of code to set for release. When we think we are "done," we create the release branch with the intention that it is unlikely to change. And if it does change, we want that to be tightly controlled and very well checked. The benefit of branching for the purpose of a release is that we can then continue to work on the trunk without fear of hurting the release. In fact, changes intended for the release after branching are first applied to the branch, and then merged down to the trunk, either as they come in, or when the release is ready by doing them all en-masse.
<p>With preview releases, we are making the branch-to-release timespan very short&mdash;one day at minimum, and usually about one day maximum. However, it depends on what we find out during the process. This is called &quot;baking&quot;. It gives us one day to say, &quot;Oh no, I forgot to...&quot; after we all think we are done. Our brains think differently when we think we are done, and we tend to remember things we didn't think about earlier. It's like remembering the fishing bait when you are one mile from your house on the way to the lake. Everyone has their distance from home where they turn to their fellow travelers and say, &quot;Hey, did you bring...&quot; We'll find our best distance for the framework development as well, starting with one day for the preview releases and extending that to be much longer for major releases.</p>

With preview releases, we are making the branch->release time span very short, 1 day minimum, and usually about 1 day maximum but it depends on what we find out during the process. This is called "baking." It gives us 1 day to say "oh crud, I forgot to..." after we all think we are done. Our brains think differently when we think we are done, and we tend to remember things we didn't think about earlier. It's like remembering the fishing bait when you are 1 mile from your house on the way to the lake. Everyone has their distance from home where they turn to their fellow travellers and say "hey, did you bring the..." We'll find our best distance for the framework development as well. Starting with 1 day for the preview releases and much longer for major releases.
<p>Two terms that we use with branches:</p>

h3. Two terms that I use with branches that I'll share:
<p><strong>Rebase</strong><br />
This is the branch accepting code from its ancestor to &quot;refreshen&quot; its contents. This is usually done with parallel development. For example, someone maintaining an experimental branch is working on ideas, and wants to update from the main working team periodically. They'll rebase as needed to bulk-merge changes into their branch.</p>

*Rebase:* this is the branch accepting code from its ancestor to "refreshen" its contents. This is usually done with parallel development. For example, an experimental branch is working on ideas, and wants to update from the main working team periodically. They'll rebase as needed to bulk-merge changes into their branch.
<p><strong>Promote</strong><br />
This is taking changes and pushing them back to an ancestor branch (or between sibling branches). This is usually done to take tested changes done in isolation of a branch back to the main working body.</p>

*Promote:* this is taking changes and pushing them back to an ancestor branch (or between sibling branches). This is usually done to take tested changes done in isolation of a branch back to the main working body.
<p>Using these two terms in our context, we will rarely &quot;rebase&quot; unless we have long-running experiments underway, or otherwise if we find we just branched for release way too early and need to go at it again. And we use &quot;promotion&quot; when we have a release branch taking emergency, last-minute patches that we want to promote back to the trunk for ongoing development. </p>

So using those two terms in our context, we will rarely rebase unless we have long running experiments underway or if we find we just branched for release way too early and need to go at it again. And we'll use promotion when we have a release branch taking emergency, last-minute patches that we want to promote back to the trunk for ongoing development.

If you want cool pictures and graphs, [this PDF|^SCMBranchingModels.pdf] shows the model well. We are using the "branch by purpose" model. Or at least something close to that. We branch later than the paper describes as they branch near feature-complete or some time earlier than "done."
<p>If you want cool pictures and graphs, <ac:link><ri:attachment ri:filename="SCMBranchingModels.pdf" /><ac:link-body>this PDF</ac:link-body></ac:link> shows the model well. We are using the &quot;branch by purpose&quot; model, or at least something close to that. Also, we branch later than the paper describes, as they branch near feature-complete or some time earlier than &quot;done.&quot;</p>