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

I am wondering what is the best way to handle the situation of marking a bug as resolved and providing a version of component/product in which this fix can be found.


For a project I am working on, we are using Bugzilla for issue tracking, and we have the following:

  • A product "A" with a version number like vA.B.C.D,

This product "A" have the following components:

  • Component "C1" with a version number like vA.B.C.D,
  • Component "C2" with a version number like vA.B.C.D,
  • Component "C3" with a version number like vA.B.C.D.

Internally we keep track of which component versions have been used to generate the product A version vA.B.C.D.

Example: Product "A" version v1.0.0.0 has been produced from component "C1" v1.0.0.3, component "C2" v1.3.0.0 and component "C3" v2.1.3.5.

And Product "A" version v1.0.1.0 has been produced from component "C1" v1.0.0.4, component "C2" v1.3.0.0 and component "C3" v2.1.3.5.

Each component is a SVN repository.

The person in charge of generating the product "A" have only access to the different components tags folder in SVN, and not the trunk of each component repository.


Now the problem is the following, when a bug is found in the product "A", and that the bug is related to Component "C1", the version of product "A" is chosen (e.g. v1.0.0.0), and this version allow the developer to know which version of component "C1" has the bug (here it will be v1.0.0.3). A bug report is created.

Now let's say that the developer responsible for component "C1" corrects the bug, then when the bug seems to be fixed and after some test and validation, the developer generates a new tag for component "C1", with the version v1.0.0.4. At this time, the developer of component "C1" needs to update the bug report, but what is the best to do:

  1. Mark the bug as resolved/fixed and add a comment saying "This bug has been fixed in the tags v1.0.0.4 of C1 component" ?
  2. Keep the bug as assigned, add a comment saying "This bug has been fixed in the tags v1.0.0.4 of C1 component, update this bug status to resolved for the next version of the product that will be generated with the newest version (v1.0.0.4 of C1)" ?
  3. Another possible way to deal with this problem.

Right now the problem is that when a product component CX is fixed, it is not sure in which future version of the product A it will be included, so it is for me not possible to say in which version of the product it will be solved, but it is possible to say in which version of the Component CX it has been solved. So when do we need to mark a bug as solved, when the product A version include the fixed version of CX, or only when CX component has been fixed ?

Thanks for your personal feedback and ideas about this !

share|improve this question
up vote 2 down vote accepted

Fix in the component and integration of the fixed component into the product are two different activities.

There could be many ways to handle that, but no matter what you choose, you better take care that above difference is easy to understand by those using bug tracker.

Straightforward solution could be to simply use separate bugs for these separate activities.

  • Ticket 1234. Fix <particular issue> in component "C1".
  • Ticket 1235. Integrate fix of <ticket 1234> into product "A".

That way, you get clear description of what should be done, you can assign, prioritize and schedule the tickets independently, only taking into account that integration can start after component fix is completed.

Also, that way allows handling more "multi-level dependencies", like first one needs to fix a library component X, then integrate and adjust component C1 and only after that, integrate into product A.

That is a good idea indeed, however it means more process and overhead for "one" bug. Providing a specific format for the bug summary could make the management simpler ([INT. FIX] "summary of the bug previously reported")...

For the sake of completeness note that above approach ("one bug, two phases") may be viable, too - especially if vast majority of your bugs integrate that way (particular version of component -> particular version of product).

I've seen it done in at least two different projects and it worked OK. It typically took some time for team newcomers to get used to workflow and in cases of more complicated integration, we used separate bugs to track that, but that's minor.

  • Besides additional state (INT.FIX in above quote), points worth considering for "two-phase bug life cycle" are dedicated fields for component and product versions, as well as for responsible engineers. These are not a matter of life and death though - if there are no dedicated fields, relevant data can be extracted from bug changes history or put to comments.

And, since you mention overhead, my firm belief is that any substantial overhead that may be related to bug tracking means something is wrong either in bug tracker or in project management, or both.

share|improve this answer
That is a good idea indeed, however it means more process and overhead for "one" bug. Providing a specific format for the bug summary could make the management simpler ([INT. FIX] "summary of the bug previously reported"). I will wait for some more answers before making my choice of accepted answer ;) – Vincent B. Jul 5 '12 at 8:50
Actually, I think this is a good answer. You will always have "more process" when a bug is fixed in one product (library, say) and the result is integrated into another product to fix the issue for the customer, than if you had simply one monolothic product. There is no way around that. Using two tickets for the separate activities of bug fixing and integration allows actually treating them as completely separate issues. Case in point: what if the bug fixed in 1234 also affects separate product Q? – Michael Kjörling Jul 5 '12 at 9:25
This seems to be a reasonable and scalable (for components that are used in multiple products) solution. If the second ticket seems to much work try and automate it as much as possible, streamline the process don't bend it. – sebastiangeiger Jul 5 '12 at 13:59
@Michael Kjörling: Thanks for your answer, that is a pertinent point you highlight ! sebastiangeiger: Yes you are right, I will think of a way or flow to follow that the team should respect to insure it is done and is as painless as possible. – Vincent B. Jul 6 '12 at 1:21

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.