How to manage ticket status by release branch

[Stefan Seefeld]

In our work we typically deal with multiple product versions in parallel. One version may already be deployed, another about to be released, and a third be in development.

When a new defect is reported, it may be "deferred" for the upcoming release, but "in progress" (or even "done") for the development branch.

What is the best way to reflect such a workflow in jira ? Can a ticket have multiple states, depending on the target release ? Or would you advise for keeping target-branch specific clones of the ticket ?

[Bill Sheboy]

Hi @Stefan Seefeld 

Jira work items have Fix Version and Affected Version fields.  Have you tried using those to track when a work item will release, and for defects which current releases they impact?

• https://support.atlassian.com/jira-software-cloud/docs/jql-fields/#Fix-version
• https://support.atlassian.com/jira-software-cloud/docs/jql-fields/#Affected-version

Kind regards,
Bill

[Stefan Seefeld]

Yes, we are using those fields. But in some contexts it's preferable to have tickets marked as "deferred" (with respect to a particular release), and thus the way it was used is by cloning the tickets, so different releases would have their own clones. Neither an elegant nor efficient approach, IMO.

[Bill Sheboy]

For "deferred" you could just clear the Fix Version field until the work is built / scheduled for delivery.  And...a Label value could be added to indicate the "deferred" state for tracking purposes.

[Stefan Seefeld]

But that's the thing: there is no "until" ! The ticket *is* fixed for a given version (on a given branch), but still needs to be marked "deferred" for another. In other words, what I'm looking for is to have contextual states, i.e. "deferred for release A" *and* "done for release B".

I don't think the "fix version" is providing enough information. Consider for example a case where the bug was found in version 1, is fixed in version 3, and now there is a formal discussion on whether to backport the fix to version 2 or not.

[Bill Sheboy]

You are correct: that functionality does not exist for the existing features.

A workaround could be adding custom fields specifically to record deferred versions, etc.

Before doing that I recommend pausing to discuss with the team: what would we do if we already had that information today?  How would we act differently?

Knowing that may help your team decide how to mitigate / solve this need.