Use a custom field to manage releases/versions

[rafaferreira]

My understanding that Jira manage Releases by fixVersion, but I'm wondering if I can customize Jira to use a custom field that I created (e.g.: targetVersion).

In our process, fixVersion means the version that my ticket got fixed, not the target version that we plan it. So we created a targetVersion that is the desired version that a given ticket will be fixed so I would like to manage my Releases on top of that.

[Bhushan Nagaraj]

Hi Rafael,

JIRA provides 2 fields to manage releases.

Affects Version - version in which problem was found

Fix version - version in which problem will be fixed/is fixed

Versions can also be marked Unreleased and Released.

Hence, if you have an issue that is assigned to a Fix version that is currently Unreleased - you are still working on fixing that issue. And if you have an issue that is assigned to a Fix Version that is currently Released - you have already worked on the issue, fixed and released it.

If the above does not fit your process, you can create a custom field of type "Version Picker" in JIRA. 

Hope that helps.

Cheers

Bhushan

[rafaferreira]

@Bhushan Nagaraj, thanks for your quick answer!

Our big problem is exactly the slash '/' in your phrase:

Fix version - version in which problem will be fixed/is fixed

Our releases are not rolling out in a good cadence so for us is important to clearly differentiate: target version and fix version (aka. version in which problem will be fixed vs. version where the problem got fixed).

This process is in place for a long time, but doing that I can't properly use Jira releases.

A quick solution for us would be if I can customize Releases to consider our 'custom field type "Version Picker" that we call "Target Version"

A second idea is to create a custom field type "Version Picker" called: "Dev Fixed Version" so developers can use this one instead of fixVersion. So we are good to go and use fixVersion as suppose to.

Comments? / Ideas?

[Bhushan Nagaraj]

Hi Rafael,

The Release Hub in JIRA is not customizable to choose a different Fix Version field. It only works with Affects Version and Fix Version field. 

Considering the above, you might want to go with the second option where you use a custom field to capture initial target release, and set the fix version to the version it was actually released in. This way, you can use Release Hub as intended to.

While tools help us solve some of these problems, I would highly suggest focusing on what is causing the release issues in your delivery pipeline.  Recently, Atlassian launched the Team Playbooks to help teams with some of these issues. I would highly suggest taking a look at the Team Health Monitors and running a session with your team.

https://www.atlassian.com/team-playbook/health-monitor

Cheers

Bhushan

[Helder Rossa]

A Version it's different from a Release. And so, when we change the status to Release, this means that the release of a specific Version has all the issues that are RESOLVED/CLOSED.

But, that's not the all truth.  A Release could have issues that are in other status. Example, we can go to a Version detail and see something like:

• 10 Issues in version
• 8 Issues done
• 0 Issues in progress
• 2 Issues to do

Also, Jira RoadMap Gadget, expects that, we would plan a Version, filling the 'Fix Version' field.

So, if the 'Fix Version' field was only to put 'fixed' (I'm guessing RESOLVED/CLOSED) issues, then the actual Details on the Version, and the Jira RoadMap Gadget didn't make sense.

Further more, the 'Affected Version' field does not associate an issue to a Version. And that's a problem also. In the detail of a Version we can't see this issues.

After this, how can we, in Jira, do proper RoadMaps, associating issues to a Version (aka Target or Planed Version) making use of Version detail and Jira RoadMap Gadget and also, when we fix the issues, mark them has Fixed in Version'?

I think the name 'Fix Version' is improperly named, has it's now. Because this field only marks the issue has 'In Version'. It's the ONLY field that associates an issue to a Version!

My personal workflow it's doing something like:

1. Create a 2.4.next Version, associate to 'Fix Version' field and plan my NEXT 2.4 release.
2. After that, when the release it's finished, I will rename it to the final Version number (ex: 2.4.12) and do the Release.
3. After that, for planning a new Version for the 2.4 it's created a new 2.4.next Version and start all over
4. For planning multiple Versions, I would need to do Version 2.4.13 and 2.4.14.
5. Note that the same 'fix' could be in 2.4 branch and 2.3, so, the same issue, could have multiple Versions releases/plannings.

What this means is that the 'Fix Version' it's really and only, the association of the Issue and a Version and not the 'status' that it's 'fix' in a Version. The status of the issue defines if the issue it's 'released' (fixed) or yet to be 'released' (still not fixed).

[deepu]

Hi, I want to configure my release using script runner. When there are issues in a version that are not closed, I don't want the release to happen. If someone try to release without closing the issues in the version then they should not be able to go through with the release. Is it possible using script runner for jira?