Well, it depends, but every source control system I know requires a separate merge for each branch. Even if it didn't, you would need to test separately on each

Well, it depends, but every source control system I know requires a separate merge for each branch. Even if it didn't, you would need to test separately on each branch anyway. IBM - at least the project on which I contracted - required a ton of paperwork for every change that could be deployed to a production system. Analysis of the bug, how it was fixed, alternatives considered, test plan... and those were the more rational pieces of the paperwork. This is not a bad idea, though it is not fast. At the minimum, I'd suggest a unit test and an integration test tested and checked in against each release. Any deviations per version (and it is possible!) need to be thoroughly documented and tested. Others would likely live closer to the edge, but this is on production systems you do not control, I presume. Every time this is inadequately fixed costs both you and the customer quite a bit of time and frustration. (Many changes, the customer will have a staging system where they will test the changes for a week before moving it into production.) PS, don't be surprised when customers run three or four versions behind. I worked in one place where they had a heavily customized solution, and on top of that they developed hooks into the back end database so that they could get what they really needed done, because the customizations didn't do the job quite right and would be too expensive to let the software company do. This is your nightmare, but it pales in comparison to the nightmare from the customer's perspective.