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?
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.