Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 46 down vote favorite
4

A bug was opened, fixed, verified and closed. A month later, it showed up again in a subsequent version after several iterations without any regression.

Provided the bug characteristics are the same, would you reopen the existing bug ID or open a new one with a link to the closed bug?

share|improve this question

5 Answers

up vote 78 down vote

Characteristics do not equal causes. The new bug could have a different underlying reason, even though it appears to be the same. So, open a new bug and point it to the old one to help the developer.

share|improve this answer
20  
+1 there are many differnt diseases with different treatments that share common symptoms. – FrustratedWithFormsDesigner Mar 28 '12 at 14:47
Would it be fair to deduce that if the bug proved to have the same cause, you reopen it? – KMoraz Mar 28 '12 at 15:05
@KMoraz: I would think so, but that's only something to be considered after the investigation proves it's the exact same cause. Since the symptoms disappeared for a while, it's unlikely that it's the exact same bug, though it could be a bug introduced into a different part of the system, but coded the same way the original bug was coded and so causing similar symptoms. – FrustratedWithFormsDesigner Mar 28 '12 at 15:14
1  
@KMoraz I'd say no. Suppose it was fixed in 1.0, 1.1 didn't have it, but it reappeared on 1.2. Unless your issue tracker lets you associate it with serveral releases at once, you'll lose the history that it was found and fixed in 1.0. Just open a new bug. – Andy Mar 28 '12 at 18:43
1  
@Andy Don't think it changes anything, but maybe 1.1 had it and nobody noticed... – joshuahedlund Mar 28 '12 at 20:29
up vote 33 down vote

If it was verified and closed, and worked for a while, and then appeared again after something was changed, then it's not the same bug. It may manifest itself similarly as the old bug did, but its cause may well be different. So it's not the same bug. So I would open a new one, with a link to the closed bug.

share|improve this answer
up vote 15 down vote

Open a new bug, always. Why? Suppose it turns out to be identical to the previous bug, and you've released the fix for the previous bug. Your release notes will document that "Fix Bug XXX." From the point of view of issue tracking and making the release notes clearer, it is preferable to refer to the new bug "Fix Bug XXX+1 (which was similar in cause and effect to Bug XXX)" rather than to say "Fix Bug XXX (Again)" or something similar.

share|improve this answer
2  
Citing bug IDs in patch notes is just.. very unfriendly. – Andreas Bonini Mar 28 '12 at 18:49
3  
@krelp It is helpful when you are working with a vendor to get an issue fixed and you can track the bug ID you received with a bug id in the release notes. – Darryl Braaten Mar 28 '12 at 20:00
1  
@Krelp I wondered why that's a bad idea, so I asked here: programmers.stackexchange.com/questions/142258/… Perhaps you have some input on that? :) – tnorthcutt Mar 30 '12 at 14:35
This is a good point – KMoraz Apr 1 '12 at 8:10
up vote 3 down vote

Generally speaking, open a new bug.

However, if you are allowed to do some investigation first, I would check your history in source code.

If you work in a team environment, somebody may have old code on their system (i.e., they didn't do a Get Latest after the original fix was checked in), made changes, and then checked in without doing a diff. Bad practice, sure, but it happens "all the time."

Looking at the history of the file(s) where the bug was fixed will quickly confirm or eliminate that as a possibility.

share|improve this answer
1  
"(i.e., they didn't do a Get Latest after the original fix was checked in), made changes, and then checked in without doing a diff"... if that happens your source control system is broken – JoelFan Mar 28 '12 at 20:13
@JoelFan - not necessarily. Sometimes auto-merge doesn't work correctly, and sometimes manual merge does not work correctly either. Or, it could just be the case that they missed the change when they did the diff, etc. All I'm saying is that this smells of human error, and a 2-minute check of the source control history may save a lot of hassle. – Wonko the Sane Mar 28 '12 at 20:29
Checking the history is worthwhile anyway... because if your source control system is broken, you want to know that. – mjfgates Mar 29 '12 at 8:30
1  
If that happens all the time, it's not the SCM that's broken, it's your development team... – Daenyth Mar 29 '12 at 20:36
up vote 1 down vote

I agree with the previous posters' suggestion to open a new bug since it may not end up being the same root cause.

My further recommendation would be to ensure you're always adding unit and integration tests that cover the bug so that in future versions you catch the problem right away before it goes out to your clients. Nothing looks worse to a client then seeing the same bug come back.

share|improve this answer

Your Answer

 
discard

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.