Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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?

 

2 comments

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

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

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

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.

Like Bill Sheboy likes this

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Confluence

Introducing External Collaboration for Confluence

We’re excited to introduce external collaboration for Confluence, now available in early access. It is available to preview for Confluence Cloud Premium and Enterprise customers. (If you're not on ...

218 views 0 8
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you