Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

A few people have asked, so let me explain our release model from a SVN perspective.

A basic mantra to keep in mind is: "We work on branches and deploy from tags"

So what does this mean?

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.

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.

Two terms that I use with branches that I'll share:

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.

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.

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 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."

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.