Suggestions on bug lifecycle and release management

Our group is currently analysing our procedures for managing formal software releases and integrating with a bug lifecycle.

What bug lifecycle model do you use? And why?

For example assume a that formal releases are generated for QA once per week. At what point do you mark bugs as resolved?

• When the developer has committed their changes?
• When the chang开发者_运维百科es have been reviewed and merged into the release branch?
• When the formal release candidate has been created?

And what process, or features of your bug tracking sofware, do you use for tracking this?

Are there any tips/suggestions/recommendations that you can share?

If you are lucky enough to have a unit test that catches the bug, or if you are able to add a new test that specifically tests for the bug, it offers a good and objective measurement of resolution.

If you do continuous builds with regression testing, then as long as the corresponding test passes on your primary branch, the bug can be considered resolved. The advantage of this is that it makes it easy to consider a bug resolved on one branch but not resolved on another, leading you to attempt integration early and have a measurement of success.

Depending on your culture, you may want to only have a bug marked as truly resolved if it passes automated builds in all branches.

A side advantage is that you can catch the bug if it reappears in the future, for example due to someone reverting something or a merge catastrophe.