CM: THE NEXT GENERATION of Branching Standards

change that can be merged into the main trunk when it switches to the right release (at least when it's future work).  Instead, since we have a branch per stream capability, you simply make the change in the Stream for the release on which you're working.  In fact, you no longer need a "main" trunk.  Instead, you set your context to the Stream you're working on, whether it's a support stream, future development or the current development stream.

3.  Work Flow Promotion: Ready for build, Integrated, Tested, Production
Most shops have some sort of work flow promotion for their Updates (or in many cases Files).  It may be as simple as: In Development, Integration, Production.  Or it may be more elaborate.

First of all, work flow promotion belongs on the Update (i.e. the change), not on a file.  To do otherwise is to risk getting partial changes promoted.  CM tools or processes that do not support some form of change packaging are going to cause problems.

The next thing to notice is that many processes are geared to allow any Update to be promoted in any order.  This allows maximum flexibility.  Well, not quite.  This pessimistic view (i.e. that any Update can be promoted in any order relative to other Updates) requires a process that has separate branches for each promotion level and requires merging at each promotion step.  Who is responsible for the merging?  When does it occur? What about the separate post-merge testing?  What happens if the process needs a new promotion level inserted?

In the optimistic view we realize that Updates are normally (in fact almost always), checked in to the repository in the same order that they will be promoted.  We're not talking about a strict Update-by-Update ordering here, but rather an ad-hoc grouping of Updates promoted in the same order that the group was checked in, as promotion beyond the developer tends to occur in batches.  For example, each night, all "checked in" Updates might be selected for the Build. At first glance this appears to reduce the flexibility - but let's look at this in more detail.  This view of the world actually works very well, in both small and large projects, but requires some good software engineering discipline.  

If developers are arbitrarily making changes and checking them in without testing, there's going to be a lot of failures and the resulting Updates are certainly not always going to flow through the system in the same order.  This model is simply not going to be valid.  However, if code is unit tested and peer reviewed before being checked in to the repository, odds are that your processes are geared to the expectation that checked in code will be promoted.  

Typically, checked in code is rolled into a Build and only if there are build problems are some of the Updates rolled back, corrected, or supplemented with a fix (i.e. another Update).  So how often do you roll back Updates as a percentage of all Updates selected for your builds?  Likely this is a very low percentage.  So instead of managing parallel branches for your promotion levels, you could be dealing with this very low percentage (which you have to deal with anyway) as a higher priority item.  If this is the case, then your promotion levels, instead of being separate branches requiring merges and additional administration, could simply be configuration lines drawn at various promotion levels in your Stream branch.

Ideally, with adequate tools, these lines are drawn automatically, based on the context view.  This is where Promotion Level (mentioned earlier) comes