When it comes to CM plans, each project has to clearly identify its own strategies for branching, and subsequently for labeling and merging. There are many different practices for branching, and many different philosophies. Each CM group will vigorously defend it's practices and document them in a "Branching Strategy" document for use by the development team.
In this article we explore a potential standard for next generation branching, one which requires advanced capabilites and processes, but one which can significantly reduce CM complexity and increase CM automation. As well as using it myself, and with a number of clients, I've seen many other companies migrate in the direction of Stream-Based Branching, in part or in whole, with a goal toward clearer, less complex, more automated CM.
Branching should always arise from one common theme: the need to support the existing codeline. From the ground level, this is not always an easy call. For example, if "they" send a build to the verification team, and I'm starting on a new feature, do I have to create a branch so that I can continue to support the code that went ot the verification team? What if I'm changing an API - do I need to create a new branch so that it doesn't affect other existing code? You may have very definite answers to these questions, but the simple answer to both of them is: It depends. It depends on whether or not you have to support the previous code line. Wait a minute... didn't I cirularize my argument?
OK. Let's take an example. Let's say I change an API. Well, if it's not yet being used by anyone, no problem. If it is being used, but the changes are all upward-compatible, not requiring other code to change, again no problem. If the changes do require other code to change, but I package the changes to all the other code as part of the same change package, again no problem. If I'm just making a small innocent change which is totally upward compatible, requiring no other code changes, but the release baseline is totally frozen in preparation for launch day - then, no way! We don't want any changes that could possibly affect the release schedule - and simple software changes that go wrong have a certain track record. So, it depends.
Branching is always a gut-wrenching issue. If I branch, I have a new branch to support, to label and, possibly, to merge. If problems come up that need to be addressed while the branch is in effect, I have another place where it has to be fixed. How do I decide when the branch will merge back? What happens if I determine a new branch has to be created off the old branch for another reason? How will I eventually reconcile them? What about a branch off the new branch? Now let's look at the new release development - is the same thing happening there? I'm responsible for 100 files - how do I keep my sanity through all of this? Or what if I change jobs - how does the next person deal with it all? Well this is why we have Branching Strategies.
But a Branching Strategy is far from a Branching Standard. Give me two different developers, or a developer and a CM manager, and I'll show you two different points of view on branching. Why are there so many different branching practices? Is it possible to focus on one or two practices that will do the job in a large number of cases?
Let's start out by looking at branching from above the forest. It could be very simple: Branch into a new release for changes that are not to be included in prior releases, and otherwise don't branch. That covers the parallel release management view. But what about all of the other reasons we branch?
I've said it before,