To best understand our release model from the point of view of Subversion, keep this in mind: "We work on branches and deploy from tags."
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 "trunk" branch for all development and take a slight slowdown each milestone (i.e., "release") 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 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-to-release timespan very short—one day at minimum, and usually about one day maximum. However, it depends on what we find out during the process. This is called "baking". It gives us one day to say, "Oh no, 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 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, "Hey, did you bring..." 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.
Two terms that we use with branches:
This is the branch accepting code from its ancestor to "refreshen" 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.
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.
Using these two terms in our context, we will rarely "rebase" 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 "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. Also, we branch later than the paper describes, as they branch near feature-complete or some time earlier than "done."