Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Single Issue, multiple releases at different times.

Emily Jarvis
Contributor
June 25, 2018

Can I have one issue get marked done in one release, and then reopen it for a different release? Sadly, the two releases are done days apart and the same Jira issue needs to be QA’d in two different versions so it has to go through the workflow twice. Is this feasible to have only one issue without linking or duplicating the issue? How will that affect reports on releases, time tracking, etc? If I have to create a new issue and link the two, will the work tracked against them both roll up? Can I do a report on the "one issue" even though it's two linked issues?

Allow me to explain my release cycle for better reference, bear with me:

Our public releases consist of a major version followed by any needed point releases before we move to the next major version. We aim to have as few point releases as possible. Examples:

  • Version 17 is 17.1.0.0
  • Version 17 (Release 2) is 17.2.0.0
  • Version 17 (Release 3) is 17.3.0.0
  • Version 18 is 18.1.0.0

We also have private customer builds. These are given to customer(s) that contact us about a bug. We rely on the customer to QA, but we do move them to the next major version or point release to get QA's internally. Examples:

  • The 15th bug identified in Version 17 (Release 3) is 17.3.0.15

Due to our government customers having to stay one major version behind, whenever we release a new version, we immediately follow that with a public point release for the previous version. (This incorporates all customer builds.) Examples:

  • Released June 1st = Version 18 or 18.1.0.0
  • Released June 2nd = Version 17 (Release 4) or 17.4.0.0

Here’s where I’m having the issue. Let’s say issue #DEP-91 is that 15th bug.

  • #DEP-91’s ‘Fix Version/s’ will be ‘Version 17 (Release 3) Customer’, “Version 18’, and “Version 17 (Release 4)'.
  • #DEP-91 will be internally QA’d in ‘Fix Version/s’ ‘Version 18’ and be marked Done, so it will be included in the Release Notes of 'Version 18' in Jira.
  • #DEP-91 will have to be reopened and put into QA so it can be internally QA’d in ‘Version 17 (Release 4)’. Again, it will have to be marked Done a second time so it will be included in the Release Notes for this version as well.

Does anyone have any suggestions on the best way to handle this in Jira? In our previous bug tracking software, we would just move the issue around from release to release and reopen it each time. 

Thank you!!

1 answer

1 accepted

1 vote
Answer accepted
Boris Berenberg - Atlas Authority
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 25, 2018

It can be done, but it will break all the reporting. I would suggest making a duplicate issue for the second QA phase.

Emily Jarvis
Contributor
June 26, 2018

Boris, 

Thank you so much for this reply and reading my entire question. :) Would duplicating be best or would you create a sub-task of the original one so that time logging can be rolled up into the original issue?

Thanks!

Boris Berenberg - Atlas Authority
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 26, 2018

That will depend on your organization needs. Both can work from a technical perspective. If you want to roll work up in the same issue then a sub-task is likely a good way to go. In fact, you may want a sub-task for both of the phases, and let the parent issue stay open the whole time. 

Emily Jarvis
Contributor
June 26, 2018

That's probably the best bet, thank you for the answer.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events