Dual Maintenance

: The problem is not version control branching. Version control branching is one (common) solution to the particular problem of having to support the maintenance and evolution of more than one version of the codebase at a time. This is typically called the DualMaintenance problem or the MultipleMaintenance problem.

No one that I know likes having to do DualMaintenance. It always adds more work and complexity. Branching (if done right, using a Mainline and other key ScmPatterns) is one way of managing and minimizing the additional overhead that DualMaintenance entails. --BradAppleton

Why/When is DualMaintenance Necessary?

There are many reasons why. Most of them are context-specific and relate more to business reasons than technical reasons, though there are some technical factors as well.

Some of the reasons have to do with trust/fear on the part of the customer:

Fear of instability of the application
Fear of instability of the application environment that must be compatible with your product
Fear of disruption to the customer's business environment due to deployment/upgrade issues such as major hardware upgrades, major schema upgrades (or formatting changes) requiring system down-times, and re-writing of queries, reports, and utilities depending on the previous schema/formats
Fear of disruption to the customer's business processes and training and documentation that would need to be changed even if there is no need to fear instability of your product or its operating environment. The up-to-date version is much better than what they have now: It has many new features and an improved user interface. But this means that the users will need training before they'll feel comfortable with it. (Yes, the opportunity to do new things is a scary prospect to some users.)
Many customers require requalification of new releases, which can take a long time. A small set of deltas from their current release that can be tested are usually acceptable. All this is contractual by the way. Usually telcos, nuclear power plants, etc do this kind of thing.

Sometimes our app isn't backwards compatible:

The new code runs on Pentiums because they are 53,429x faster, but many of our customers don't really want to upgrade their $BIGNUM hardware. And we'd rather branch than make the code adaptive because it's a legacy app: everything is statically linked, and the new code needs new and incompatible libraries.
The new code has added 17 fields to the database for new features, and the customers don't want to be down for the 3-day database conversion (the db has 1.3 bazillion records). And we'd rather branch than mutate the records incrementally because it's a legacy app: mutating the old records practically means moving them into a different database.
Also, a release is made of many features that may have a certain dependency order. And we'd rather branch than remove the dependency. Each feature must be system tested, not just unit tested, before it can folded back into the code base.

Some of reasons have to do with mandated contractual obligations to provide such maintenance as a condition of work. Some may have to do with standards or regulations for the specific domain or customer (particularly if they are a subcontractor and give their work which depends on your stuff to others to incorprate into other products). This is common with government contracts for example, or with large infrastructures such as those for wireless and wired communication, or even for software used for utilities such as waste-management, power, traffic/transportation, and several others.

And there are scores of other reasons that might occur on a case-by-case basis. Which is why whether or not to support DualMaintenance is more of a business decision than a technical decision. Once the commitment has been made, it typically takes "only giving them the latest version which includes the fix" off the table as an acceptable alternative. And then you need to decide whether or not to use version-branching to solve the DualMaintenance problem, or some other attempted solution that supports multiple independently evolving configurations of the codebase.

Ultimately, it depends on more factors than XP (or any development methodology) gives much control over, like the size and distribution of the customer base, how firmly entrenched is the customer's use of the tool with their environment such that deploying a new version cause disruption (either to the environment, or to all of their own processes and training, and other infrastructure) to update, and even the application domain itself. For better or worse, whether or not to provide legacy support for maintaining multiple versions and to what extent they are maintained is a business decision that is meted out in support-agreements, SLAs, and maintenance fees.

Why not just release the current version with the needed fix?

The question above is about how to avoid having the DualMaintenance problem, not about how to solve the DualMaintenance problem once you have it. The question speaks to a different problem. Definitely avoid having the DualMaintenance problem whenever you can.

It is certainly a good question to ask to challenge whether you really are in one of those unavoidable situations - So if you havent asked it yet, you certainly should. And perhaps the answer should even be periodically revisited to see if the current relationship with the customer(s) would allow you to eliminate having to do DualMaintenance from that point onward.