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!!

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Single Issue, multiple releases at different times.

Emily Jarvis

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!!

Accepted answers

Boris Berenberg - Atlas Authority

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

All comments

Boris Berenberg - Atlas Authority

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

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

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

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud