Taking the Complexity out of Release Management

R3 required for R4 can be merged into R4. Or even better, choose tools that permit the R3 changes to be automatically picked up by R4 until you explicitly branch the associated file(s) into R4, in which case a merge may be required. Most work is going on in R4 and perhaps work on some major areas of R5 are starting. Your tools should be able to tell you when a change to R3 or R4 may need to be applied to other release streams.

So what we have is a 2-Dimensional (2D) release branching strategy. Instead of the traditional "main" branch, there are Release Streams. There's really no need to hold up R4 while R3 stablizes. You may wish to focus initial R4 work in more stable areas to reduce the need to merge R3 changes into R4. But the 2D model allows you to have true parallel development, and with the right tools you’ll have minimal branching. If your tool, team or process forces you to branch or re-label all of the components in order to start R4 development, you need to make some changes.

Are you wondering if your project might be too complex for a 2D model? Well I created my first real CM tool for a 25-million line telecom product in the ‘70s and ‘80s, with various product variants and thousands of developers. Not only was the 2D model sufficient, it was necessary!

As a side note, if you really want to minimize branching and merging, make sure your CM tools let you check in your changes before the build manager is ready for them. If developers have to artificially hold back on submitting finished changes, for whatever reason, the requirement for parallel checkouts (and in most tools additional parallel branching and merging) will grow dramatically. A good CM tool will eliminate the need for most parallel checkouts, including branching, labeling and merging, and will permit your components/files to follow a your product road map. Investigate the change promotion model carefully to ensure that software is checked in one or two stages before it may promoted into a build.

Manage the Superset - Build and Deliver Subsets

With a 2D release framework which is easily mapped to the Product Road Map, consider variants, customizations, etc. Do not get into the business of managing multiple baselines for these. If you do, you'll multiply your work and decrease quality. Be assured that when you finally release R4, it will not be finally. Design and CM need to work together here. Start with a strategy that says you're going to manage the Superset of your product component tree, but build and deliver Subsets. Your tree is going to branch for each release stream, and it should contain all of the files/components for that stream (even though they don’t have to branch yet). If you have an independently developed sub-product, such as EPROMs which encode the latest version of an IEEE standard, then you may want a separate baseline for it (if it's on a different release schedule).

Tag components, subsystems, etc. which are not common to every Build/Delivery. What you want to achieve is the ability to define your variants as a set of common components plus a set of components containing one or more of the tags required for that variant. For example, your common components might be augmented with English and Professional tags for your default build variant. Another variant will have English, German and Enterprise tags. Work with your Design team to let them know that this is how you want to do your builds.