Fix Versions definition is problematic

[andrelejeune]

Hi,

I've seen many postings where people quote the definition for Fix Versions as being the place where you either plan to fix and issue or where the issue ended up being fixed, depending on the status of the Jira.

However, Fix Versions is a multi-value field, meaning that a fixed issue can be fixed in multiple versions. But fixing an issue in multiple versions takes time and needs to be tracked. One needs to know which versions we want the issue to be fixed in, and which versions have received the fix. Using a single field to track both is problematic, it does not work.

An example of this would be the following:

An issue is found in release 1 (Affects versions is set to 1)

The issue is planned to be fixed in releases 2 and 3 (Fix versions is set to 2 and 3)

The issue is fixed in release 3. The issue status is moved to resolved.

At this point, there is no more indication that the issue was not also addressed in release 2.

All ideas that we discussed internally have a drawback:  Don't resolve the issue, then how do I know the issue is resolved in 3? Don't add release 2 to Fix Versions. Then how do I know that we intend to fix the issue in release 2?

It seems to me that the overloading of the meaning of Fix Versions is a problem. It should have just represented the versions where an issue was finally fixed. Maybe a Planned Versions would have been needed...

André

[Nic Brough -Adaptavist- · Accepted solution]

This one is a bit complex - as Jira has grown, the usages have changed, and become inconsistent.

• In plain Jira, a lot of people use it to represent the version(s) in which it was fixed, often having versions that were analagous to builds done by CI/CD systems.   This also applies to Kanban boards - when you hit "release", a version is slapped on the column to say "we shipped it"
• In Jira Software Scrum, the recommendation is to use it for the target version you are planning to fix it in.  But the meaning of version is slightly different - it's less of a build and a lot closer to a release of something
• In Jira Align, it's directly a release.  Of completed feature(s) (Note - these are Jira Epics, hoping we get the ability to safely ename soon!), ready to be released in the wild.  It is not a PI, or a partial build or even an entire feature ready to go to test systems, it is of one or more complete features/Epics that the end-users get.

[andrelejeune]

Hi Nic,

The distinctions you bring are useful. We follow plain Jira, so adding a "Target Versions" would be consistent with your first bullet.

But it would take us away from the Scrum definition. We do use the Fix Versions to represent a release, but if I create a "Target Versions", it would overlap with the interpretation Scrum has of "Fix Versions". This could become a problem for someone who wants to move to Scrum.

I am not too familiar with Align, but our definition of Fix Versions, if I add a Target Versions, would also "align" to theirs, it seems.

Having diverging uses of Fix Versions by the different Jira tools is a problem. I hope Jira could sort this out and allow to configure things to all be consistent for new users.

[Nic Brough -Adaptavist-]

My understanding is that the move is going to be towards the Align/Scaled approach.

[Jan Van Bruaene · Accepted solution]

We are going through the same challenges. Our motivation is that we need full traceability for every initial fix, but also for every backport. Thus we want every issue to run through the full workflow (confirmed - implementation - code review - doc review - resolved). We also don't want to clone every issue: every bug has really one entry in our Jira system. 

Our original idea was to not overload fixVersion and split it into fixVersion (where the issue is already fixed in) and ScheduledFixVersion (where we plan to fix the issue in). When we backport, we create a linked backPort issue where we track the full workflow and once the backport issue is resolved, we update the fixVersion of the "parent". 

However, because FixVersion is so essential for many Jira features and reports, we're steering away from that and are considering a hybrid approach. 

1. Introduce a new field: scheduledFixVersion - this is the version we plan to fix it in. 

2. We only start using that for the 2nd fixVersion we want to add. 

3. FixVersion features and reports all keep working: both the "parent" task uses it to indicate where something will be fixed, and the Backport task uses it to indicate future fixVersion.  

What does the community think of that approach? 

[andrelejeune]

Hi Jan, I came to the same conclusion as you did regarding fixVersion, it is an essential field of Jira. We decided to continue filling that field as usual to avoid disrupting how Jira works and we introduced a "Resolved Versions" field instead. When going through the Resolve transition, we enforce manually entering that field, but it can also be edited later when the Jira is closed when it is decided to merge the change. This way, fixVersion becomes really "Planned Versions" and we don't rely on it to determine where an issue was finally fixed, only to determine where we want it fixed.

We actually also have a "Verified Versions" which we have been using for some time now. The only remaining problem we have is with release notes, because some fixes appear in patch releases as well as in general releases, so we need to document it in two places. Maybe we will eventually create a "Release Notes Versions"!

One drawback with custom Versions fields is that Bulk change does not offer to add or remove only one of the entries. I had to use the REST API and a script to offer this possibility.

Regarding your approach of defining ScheduledFixVersions, I decided against doing that because I felt Jira mostly used fixVersions for reporting and manipulating Open bugs and less for reporting or updating resolved ones.

[Susan Wilson · Accepted solution]

In our JIRA instance, we created a Version Picker (single version) custom field and called it something like 'Target Release'.  The selection on the original task is the primary expected fix version (aka Target Release).  If it needs to be fixed in multiple versions, the task is Cloned and the version updated on the Clone task.  This would be repeated for every version expecting the fix so they are all linked by cloning but can be tracked and resolved within each appropriate release independently.  Hopefully, this might help you.

[andrelejeune]

Hi Susan, it looks like adding a "Target Versions" is the way to go. I considered creating a "Resolved Versions" instead but I think having a pair called "Target Versions" + "Fix Versions" is going to be cleaner than having a pair called "Fix Versions" + "Resolved Versions".

[Kim Taylor]

We tried creating a new version picker custom field, but we were surprised to learn it didn't add issues to the release version, like the Fix Version field did.

i.e. Using the custom field on an issue we would select "release version 4.6", but when we view Release version 4.6, it didn't contain the issue. What's the point of allowing us to select a release version, then? :/ 

If anyone knows how to add an issue to a release using the custom version picker, that would be much appreciated.  

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

I'm guessing that when you "view Release version 4.6", you are using a report that looks at the fix version, rather than your custom field.

[Thomas Magny-Garcia · Accepted solution]

Hi @andrelejeune 

As you said as the end of your post, in my project, the Fix versions label represents the version where the issue is fixed.
So in your example, it should only be 3. It may be 1 too, if the issue has a huge severity or the fix is absolutely needed.
To manage this case, we need to be able to put multiple fix versions to inform the users that the issue is fixed in these (fix) versions.

But, I agree the fact that we need to be disciplined to be sure to provide the right information...

It is a quite good question, in my opinion !

Hope it helps !

[andrelejeune]

Hi Thomas, we find that we can either add a new versions field to differentiate the target versions from the actual fix versions, or create complicated filters that attempt to extract the information from other fields that we also maintain. The complicated filters seem to each have holes that either miss certain Jiras or include too many, so in the end, I hope to convince our management that two fields are necessary. I wish Jira had this problem solved in their base implementation.

Thanks for your advise!