> As David mentioned, there isn’t a > single true ‘solution’ for this problem so the more information we provide > the better.
Think of it in terms of how your repository is structured: This issue was *fixed* on git branches [x,y,z] and *affected* tags [a,b,c]. This gives a clear an unambiguous pointer and workflow as to what goes where. "Affected version" can only point to a tag in git (this requires every proper release to be tagged, of course). "Fix-for" points at *all* branches (and tags) a given issue has been applied to (whether it's the same patch or a backport). Certain branches may not have anything to do with particular versions yet (branch_6x, master, major_feature_xyz), others are versions-in-preparation (branch_6_5_1; so-called release branches). The additional work (typically of the release manager) is to, when a given version is being released, add a tag of that particular release to "fix-for". If the process is followed by everyone this becomes fairly automatic and results in issues being marked as, for example: Fix-for: branch_6x, master, 6.5.1, 7.0 All of the above makes sense -- as a developer you immediately see which git branches this issue was applied to. So do people who are not developers. But like I said before, I'm not advocating for this process -- just wanted to highlight an example of how it can be done. The above process does require a fairly strict workflow from everyone involved, so it may be more suited for a corporate environment... But it is clear (to me at least), verbose, and fairly straightforward, so it certainly can be done. D. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
