David Jencks <[EMAIL PROTECTED]> wrote on 20/07/2005 03:24:46 AM: > what is the proper use of Jira for defects that occur in multiple > branches/releases? There are at least 2 issues fixed in head that need > to be backported
I found an answer at http://jira.atlassian.com/browse/JRA-7186?decorator=printable A user asked the question "We are now considering adding version management to a project. A user has this question: What if a fix has been slated for multiple versions, but the developer has only fixed it in one version so far? There is no way to mark the issue as resolved for one version but not the other. Maybe you can help explain how this workflow would be handled within JIRA." The answer was "The best way to deal with this situation would be to create a new issue for each version and link these issues if necessary. This way you will have one issue representing each piece of work that needs to be done and the progress on each version can be tracked separately. Clone issue functionality can ve handy here." Although the recommendation involves creating more issues (the clone issue function should make it easy), I think it is the safest way to manage changes to multiple versions. For example, someone may not have the time to merge a fix into all branches immediately, this method allows them to track the work outstanding on each branch. It also would remove confusion in a scenario where someone fixes HEAD and then merges the fix into a branch, but makes a mistake in the merging in the branch. The issue for HEAD can remain closed and the issue for the branch can be reopened/kept open. Comments as to whether this is the way we want to go moving forward? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
