6

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.

Improve this question

2 Answers 2

Reset to default
4

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/4.1
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.

Improve this answer
1
  • Thanks for clearly laying out the structure, this has really helped us. Commented Oct 26, 2011 at 11:37
0

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.

Improve this answer
3
  • 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. Commented Oct 26, 2011 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. Commented Oct 26, 2011 at 10:29
  • True. Thanks for the compliment about the OK structure :) Commented Oct 26, 2011 at 10:33

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.