Thanks for your input too!

Jarek

That way the merge is the responsibility of the developer who knows the fix, and (hopefully) has better understanding of how to deal with conflicts on the other branches.

OTOH – that advantage is more relevant when the person building is not familiar with the code. Which (I guess) is more a corporate scenario.

Your process definitely works. I’ve had to take on a release manager role for several years (until we can hire a dedicated RM), and I’ve found a lot of release management is just common sense. The hard part is making sure the execution is right.

I’ve found it helpful to try to minimize the # of branches you need to maintain. No matter which version control system you use, merging is always tricky. In the case where you have to work on a new feature that should not go for several releases, it might be worthwhile to code things in such a way you can turn on the feature in development, but disable it in QA and production.

Thanks for useful scenarios!

The former is indeed complicated

Let’s focus on the latter, which I deal with from time to time…

What about a scenario when you have already cut a ?soon to be released? branch, but you get a request to make an ?emergency fix? in the previous release?[...]

How I handle this is similar to what you have described:

• I switch to the branch with the release which is currently LIVE and make a fix there
• When the patch is ready I create a new tag as a snapshot of the system with this patch and push the patch LIVE
• Finally I switch back to the trunk (or the current branch) and merge it with the changes made for purpose of the fix

As you said the approach suggested by my is helpful there.

Answering your question, at a point in time trunk is current development branch, and in Subversion there are branches names ReleaseX (past releases). Also whenever something is pushed LIVE (a full build or a patch with some fixes) I create a tag so that I can easily check out the same code that is/was running LIVE.
Does it answer your question?

Cheers,
Jarek

Just be aware that you will want to modify this approach in other scenarios.

This works when one group is working on the “bug fix” branch and one group is working on the “next release” branch. What happens if you have a third group that is making changes for a much later release? In this case, you will probably want to create a separate branch for long term changes. Now you have two different branches and the trunk – it probably will happen to your project. Merging code can be even more challenging when this happens. So be prepared for that.

What about a scenario when you have already cut a “soon to be released” branch, but you get a request to make an “emergency fix” in the previous release? In this scenario, your team need to go back to the previous branch, fix the bugs in there and deploy that release. But you also need to merge those fixes back in to the trunk AND you need to merge those fixes to your “soon to be released” branch. Your setup will work fine for this scenario, just be prepared for it.

This may be out of scope of what you had in mind. You have a bug fix branch and the main line (the next release). Does that mean you have two different environments so that QA can test the bug fix version and the next release separately?