You want to maintain an ACTIVE DEVELOPMENT LINE (5). You have released versions that need maintenance and enhancements, and you want to keep the released code base stable. This pattern shows you how to isolate released versions from current develop-ment.
How do you do maintence on released versions without interfering with your cur-rent development work?
Once you release a version of a product or component, it may need to evolve inde-pendently of your primary development. While it might be ideal from your perspec-tive for your customers to simply update to new releases to get bug fixes, the reality
is that there are many circumstances where you need to make a fix based on the already shipped version of the codeline. You may need to fix an urgent problem, and the new release will not be ready in time. If your application has data-migration or a complicated deployment process for it, your customers may not be willing or able to upgrade immediately. You are often faced with the problem of how to conduct devel-opment of a future release while at the same time responding in a timely manner to all the many bug reports and enhancement requests that are inevitably going to be logged against the active development.
You need to identify what code was part of the release, and what code is in the main development stream. One way to identify what is in a release is by labeling the release in the current codeline, shipping that snapshot and then continuing to work on the mainline. Figure 17-1 illustrates this approach. Doing things this way does not allow you to fix something in a fixed product independently of the mainline. While
you need to fix bugs on released products, the current development line may be evolving in a direction that is quite different that the soon to be delivered release, and it may not be easy to quickly deliver a fix.
You can create a branch when the product ships to isolate the release line from cur-rent work. Then if there are fixes that apply to both the branch and the mainline, you need to merge the changes, or duplicate the work. Figure 17-2 shows this situation.
Figure 17-1 .Doing all your work on the mainline
Release 2 work Release
1
Release 2
Release 1 Work
You can put your new work on a branch, and ship the mainline. You then can merge back. This means that most developers need to merge their work; hopefully the released code won’t change too much over time. You may have more than one cus-tomer, each with variations of the released software; you may need to keep track of multiple releases that are derived from other releases. You can model this by the stair-case structure in Figure 17-3. This structure makes it very hard to figure out what code is common among the releases.
You can try to keep customers only on major releases.Critical bug-fixes and enhance-ments need to be effected immediately, often well before the next major release is ready to ship.
Maintenance effort (bug-fixes and enhancements) in the current release may be incompatible with some of the functionality or refactoring already implemented in the next release
Figure 17-2 .Create a Branch when you Ship
Figure 17-3 .Staircase of Dependent Branches.
Merge Fixes
Release 1 Work
/Release 1 patch /Release 2
Release 2 work /main
1.0
2.0
/main
/Release1
/release2
Linear Development
Mainline development has a number of advantages. It reduces complexity and redundant effort. Some early stage companies work closely enough with their few customers that they can focus development on what these customers need, and bug fixes are simply additions to the codeline. You can label each release point and then have your customers mover to the new release. They’ll probably get some additional features, so they won’t mind, and all of your work may be short term enough that you’ll be able to always ship your code.
With success and planning comes a circumstance where the main codeline might not always be shippable, since the infrastructure needed to support a new feature might not be ready until after the code is. Also, with more than one customer, you may not be able to get your customer base to upgrade at the same time.
You need a way to get let released code evolve independently of mainline code so that you can do bug fixes.
Split maintence/release and active development into separate codelines. Keep each released version on a release line. Allow the line to progress on its own for bug fixes. Branch each release off of the mainline.
Rather than trying to accommodate maintenance of the current release and develop-ment of the next release in the same codeline, split maintenance and developdevelop-ment off into separate codeline. All bug-fixes and enhancements to the current release take place in the maintenance line, effort for the next major release takes place in the development line. Ensure that changes in the maintenance line are propagated to the active development line in a regular fashion. Figure 17-4 shows this structure.
Propagate bug fixes from the mainline to the release line where possible. Once the mainline has progressed, you may still be making changes to the released line; Code on the release line becomes dead-end code when that release is no longer supported.
When you are ready to ship, label the code on the mainline and branch. Fix any errors on the released codeline on the branch, and merge any relevant changes back into the mainline before the next release. All work for future releases goes on the mainline.
At release time branch all code, including third party code.
Further Reading
• Streamed Lines (Appleton et al. 1998) describes more branching patterns,
• Software Release Methodology by Michael Bays (Bays 1999) discusses various types of codelines.
Figure 17-4 .Release Line
Rel 1
Work 1.0
Fixes
Rel 2
Work 2.0
/main
/release1 /release2
Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Steve Berczuk with Brad Appleton. Copyright 2002 Addison-Wesley, Boston, MA. All rights reserved