What's the best practice for version control with bugs that were created in a previous version, resolved and closed, only to re appear several versions later. Do you re open the old bug issue or do you create a new bug issue in the new version?

[Max Glaisher]

Example:

Version 1.0 has a bug called FT-1 "Photo upload bug": When a user attempts to upload a profile picture 
the app crashes. This issue is then assigned, fixed, tested and closed with no further problems on Version 1.1.

Several versions later (Keep in mind this bug doesn't appear in version 1.1 - version 3.1 and successfully
passes all QA tests), version 3.2, we identify a bug that results in the same crash as a result of a user attempting to upload a profile picture. 

Should this re open the FT-1 "Photo upload bug" which was tested and closed, or should this
be treated as a new bug FT-2 "Photo upload bug", in order to avoid the assumption that this
bug has been present throughout each version.

Considerations:

• Is focusing on the version with bugs and re open rates before the close of a version
  to monitor code and version quality vs version history of a single bug (FT-1 "Photo upload bug").
• Is best practice to track FT-1 "Photo upload bug" ..... as one occurrence across infinite versions,
  or a new bug that happened to occur twice in two different versions. 

[Ignacio Pulgar]

I agree with Robert's answer (+1'ed!).

Provided that a symptom may be produced by different root causes, I'd say it would be better not to assume that it is the very same bug, before having researched on it:

What would it happen if, after having reopened the old issue and worked on it for several days, you notice that it is produced by a completely different cause, but that it just had a quite similar symptom?

So, in my opinion, creating a new bug with the same description is better.

I would suggest linking the new issue with the old one through an issue link with a 'relate to' relationship, initially.

If, after having worked on the issue, it is determined that both issues have exactly the same symptom and root cause, then you can change the relationship to 'duplicate'.

Besides, a new issue is easier to track for reporting purposes and populating gadgets than a reopened one.

[Robert Massaioli _Atlassian_]

On the Atlassian Connect team we always raise a new issue if an old bug has been released in a previous version. Our reason is that we never want the same issue to be released twice. To accomplish this easily we either:

• Clone the original issue.
• Create a sub-task under the original issue.

I hope this helps.

[Max Glaisher]

Hi Robert. Just to clarify;

"...we always raise a new issue if an old bug has been released.." 

Working on the assumption that you fixed, tested and resolved the original bug in version 1.1. 

You now move on with your wonderful development life, and then when you notice a new
bug that results in the same undesirable result (FT-1: App crash from photo upload), you just create a new bug issue (FT-2.....) FT-1 vs FT-2 for version 3.2? 

Thanks, hope that is clear? 

[Robert Massaioli _Atlassian_]

In essence, yes. A new version means a new issue. Issue linking will let you know that they are related (if they turn out to be related).