Parallel Development Branching Strategy

Question

I am faced with with the challenge of needing to maintain two versions of the same product for an unknown period of time. I think I have come up with a workable solution, but I wanted to bounce it off the community for a "sanity check". Currently when a new feature is requested, a branch is cut from trunk, the development is completed in that branch, and that branch is merged back to the trunk. This has been the typical strategy for most places I have worked.

Recently a new branch was cut for a major feature overhaul which will result in changes not compatible with trunk. All of our users will eventually be forced onto this new version but, for a period of time, both versions will exist in the wild. Before I get to in depth, here is a diagram of what my current plan is for branching

Version:Current is what is currently released from. As Version:New is developed, bug fixes will continue to be shipped for Version:Current that will (in all likelihood) need to be merged into Version:New Obviously any new feature / bug fix for Version:New will only need to be merged down into Version:New. Once Version:Current is no longer in the field, Version:New will become the singular trunk. While I think this is workable, I think it can quickly balloon into a management nightmare. My question is: is there a "better" branching strategy that could be followed in my given case, or is this pretty much it?

Answer 1

You should choose a branching strategy that best fits your team and how they work. But what you described is a pretty common way of doing things. I would add that you might want to merge bug fixes from the current version more often than just after the current version isn't being used. If that period is long the branches could stray far enough from each other to cause headaches.

Here's a nice post about common branching patterns