On the surface, it sounds like a good idea. When thinking about it further, I think this is solving the wrong problem. Bugtrackers usually (in my experience, after 1-2 years on a project) end up with thousands of tickets, too many of them open. If after every release, you have to re-check all of them, the QA department (or whoever will do the review) will spend all their time reconfirming bugs that the engineers could easily have said "Yes, still an issue" or "Nope, fixed" after just glancing on it, compared to a tester who might not understand all the code changes.

Instead, aggregating information and making your bug tracker "clean" should help engineers knowing what's open and what's been fixed, and when doing a new release version, they should know exactly what has been fixed already.