Examples of transitioning a work ticket to closed when it is part of multiple fix versions?

Jeremy Podborny May 12, 2021

I am trying to establish a good work practice for completing (Closing) a JIRA ticket when it is part of two fix versions.  What I have tried so far is to have a ticket liked to both releases.  Then I have a sub task per release.  This gives me the ability to track the progress of the sub tasks to complete the release, but now I have a JIRA ticket (the parent) that is still open. because in many cases the other sub task is not complete because it is tied to a different release.

So this is causing me to complete a release with open tickets.

I know this cannot be something new, but what other process have people implemented in this case?

 

4 answers

1 vote
Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 12, 2021

In our environment we are using separate issues when code has to be added to different version branches.

For instance, we have a "main" version branch where we are doing continuous integration from feature branches. We apply a tag to that branch at a point in time to denote a release. If we find that we have to fix something in a previous release and also fold the same change into other previous releases, we create an issue for each release that needs the change. We prefix the Summary field to help us keep straight which issues is for which release.

For example, "HOTFIX 5.0:" prefixes the story where the code will be added to a branch that comes from the 5.0 tag. An identical story with no prefix would track the change being merged into our main branch as part of CI.

This aligns with our source control process for how we choose to branch, merge, and tag code releases.

0 votes
Bill Sheboy
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.
May 12, 2021

Thanks, Jeremy!  I haven't thought of the multiple release version path since my COTS consulting days.  Your use case makes complete sense for what you described.  I was focused on the single-trunk / release path.

Best regards,

Bill

0 votes
Jeremy Podborny May 12, 2021

Hi @Bill Sheboy  

Thank you for your recommendation, I have used the automation in Jira in other instances, but never looked at it based on the example you provided.   I will give that a try to see if if works for our situation.

When you say this is unusual, is there another way that you are aware of to manage the versions within 1 Jira project.  The reason this happens for us is we need to supply a bug fix for two different release families, for example v2.0 and v3.0 both need this fix.  This is primarily our customers cannot easily upgrade from v2.0 to v3.0 for a patch.  I don't think it makes sense for us to have another JIRA project, it is the same product.

Regards,

Jeremy

0 votes
Bill Sheboy
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.
May 12, 2021

Hi @Jeremy Podborny -- Welcome to the Atlassian Community!

I don't expect this case is new, but it is unusual.  Often teams only have one value in fixVersion (as a feature/Jira issue is released to production once), and may have multiple values in affectsVersion (for defects/bugs).  When a team believes they have multiple fixVersions for a Jira issue it is because they may be working on multiple products...and so probably should use multiple Jira issues to manage that work for each product.

Regardless, if you know you have a fixed number of values in the fixVersion field, you may be able to solve this with an Automation for Jira rule.  To do so, the rule could split the values in the fixVersion list field, access them one by one, use JQL to check for remaining open issues, and if none are found transition the parent.

Please look here for information about automation rules if you are interested in trying that approach:


Best regards,

Bill

Suggest an answer

Log in or Sign up to answer