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

Question

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?

Trudy P Claspill · Answer

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.

Bill Sheboy · Answer

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

Jeremy Podborny · Answer

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