Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At the company I'm working we support two versions of the software we develop. One version is available for customers, and one version the developers are developing new functionality in. The version available for customers is also changed by developers, to fix the bugs our customers have found.

So, for example we have a 4.1 version available for customers, and we are developing 4.2. As soon as we release 4.2, 4.1 gets closed, and we start developing on 4.3.

Currently we have two trunks, one for each version that is open for development. Every time a bug is fixed in the released version, we have to merge it in the new version too. This is extra work. Next to this, we would like to work in advance, and have a version already finished 'on the shelf', and already start on a new version. Which would mean if we fix a bug in the released version, we would have to merge it in three trunks!

Is there a better way of structuring this, and possibly eliminate the duplicate merges? Are we doing something completely wrong?

Thanks in advance.

share|improve this question
up vote 4 down vote accepted

The usual terminology here would be that you have one trunk (the code leading to 4.3) and two branches (4.1 and 4.2), even though the branch for 4.1 will be closed according to your description when 4.2 is released (at the same time that the new 4.2 branch is created).

You can avoid the three-end situation when you do your "advance work" in a feature branch that is not intended to be bug free. That is, you'd have three open ends:

trunk (will be 4.2 some day)
branches/conquer-the-world (a feature planned for 4.3)

and only merge bugfixes from 4.1 into 4.2. When conquer-the-world is finished (some point after the release of 4.2, I presume), merge it into trunk.

share|improve this answer
Thanks for clearly laying out the structure, this has really helped us. – Geerten Oct 26 '11 at 11:37

I don't understand why merging changes from one branch to another is extra work.

In the same way of thinking, you could say that fixing bugs is extra work and develop bug free code in the first place.

In other words a bug fix merge is normal work and is included in the bug fixing activity.

By the way, don't change your version control structure: it is perfectly OK.

share|improve this answer
No, it's not about the merging from the branches. It's like the following: there is a bug in the released version. A branch is made from the released version trunk. Bug is fixed. Branch is merged in trunk of released version, and branch is merged in new version. – Geerten Oct 26 '11 at 10:26
This is what I understood. The way you proceed allows to choose which bugs from release version are to be injected to new version. Not every bug fix is relevant for the next release. – mouviciel Oct 26 '11 at 10:29
True. Thanks for the compliment about the OK structure :) – Geerten Oct 26 '11 at 10:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.