Currently we have no good way to indicate that a bug needs to be backported to previous versions. We need to be able to track this. Ideally Bugzilla would allow us to select multiple milestones but this is not currently possible. Work is being done to allow this functionality but it is targeting Bugzilla 5.x. I don't think we will be able to move to 5.x for quite awhile after it is released due to Testopia. So how to other groups handle this? The main way is to clone the main bug and assign the clone to the new milestone while making the clone dependant on and linked to the main bug. This works well for some groups but it does mean you need to look in multiple bugs for the full set of information about a single bug. This would probably be more normal feeling to new contributors. We could also handle this as we have the Doc Changes needed. A field called "backport required" could indicate that after the bug is fixed in the current version it needs to be resigned to a different milestone rather than closed. This is probably the most natural for our existing users since they are already aware of the Doc Change workflow.
We don't want to start duplicating bugs so I think this needs to be one of the other two options.
Shall I proceed with adding the "backport required" field?
Michael: Yes please, I think this is going to be the best way forward.
Talking with Michael we probably need a pair of fields, "Backport Required:" and "Backport Applied:", this means we can flag which releases need a backport and when those backports are applied.
Since adding LTS maintenance the workflow has changed enough this bug is obsolete.