Search for fixVersion/affectedVersion using ranges

[Roman Wolf]

Hi community,

we are using releases in JIRA to plan our sprints and assign issues accordingly.

Problem

I want to filter out what issues where raised/fixed before or after a certain version.

Circumstances

Our version schema is something like:

• <product-name>_<version-number> OR
• <product-name>_<version-number>_<additional-information>

where underscore (_) represents a space.

<product-name> is a string of letters

<version-number> is of format 1.2.3.4 (semantic versioning with 4 numeric digits)

<additional-information> is a string of letters

Approach

I tried JQL and specified the range with "<", "<=", ">" or ">=" like:

project = xxxx AND type = Bug AND resolution in (Fixed, Unresolved) AND affectedVersion <= "<product> <version>" AND fixVersion > "<product> <version>" ORDER BY affectedVersion DESC, fixVersion ASC, priority, component DESC

Unfortunately when I looked into the results version are included which should be skipped.

I assumed JIRA is treating the release version as String and therefore apply some kind of String comparison. But this does comply with the results I get. So something else must happened while executing the JQL on the database.

Current Workaround

As a workaround I am currently using "in (...)" and "not in (...)" specifying each and every version directly.

This has the big disadvantage that with every new version created in the JIRA project later on I have to adapt all queries of that type which should be avoidable work.

Question

How to achieve that I provide only 1 version string and the JQL query returns me the before/after results?

Do we need to change our version scheme? Is there any other operator in JQL to work with a single version string?

Thank, Roman

Answer

Regardless of how the version description looks like SORTING is driven by the arrangement of the versions under Project > Releases.

Open the Releases page and sort all your versions there. Make unreleased and released versions visible and sort the top to bottom which means newest to oldest.

The range in your JQL will be applied according to this order.

Here on our project versions are created any time (newer once, intermediate once and etc.). So the order is chaotic after that. The project lead just has to apply the correct order ét voilá it works out as expected.

[Daniel Turczanski - JQL Search Extensions · Accepted solution]

Hi @Roman Wolf ,

I described how the version ordering works here, in the Basics section: Searching issues by version with JQL 

The ordering wasn't intuitive to me before I discovered the rule.

[Roman Wolf]

Hi @Daniel Turczanski - JQL Search Extensions

this is the hint I was looking for. Will try it out and provide my feedback here.

Thanks, Roman

[Keith Richardson]

Thanks @Daniel Turczanski - JQL Search Extensions  - just stumbled upon this and that was helpful.

[Trudy Claspill]

Hello @Roman Wolf 

I don't have an answer to your question, yet, but I wanted to throw a piece of information out for your consideration.

The > and < operators cannot be used on Text fields, as per this:

https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-operators/#Advancedsearchingoperatorsreference-GREATER

It can only be used on fields where the data in the field can be ordered.

I think, based on examining search results on my system, that the comparison is being done against the unique numeric ID assigned to the Version. If you go to the Releases page and click the link for a Version, you'll see that the URL that is displayed include a numeric ID

https://yourcompany.atlassian.net/projects/XYZ/versions/10232/tab/release-report-in-progress

See if your search results align with the idea that the comparison is between the IDs of the versions rather than names you've assigned to the Versions.

[Roman Wolf]

Hi @Trudy Claspill ,

thanks for the hint. I tried the JQL by using version ID but it does not work out on our project.

You might right, that version comparison is based on the ID. Unfortunately the versions in the project are not created in the sequence they are released. That's why the IDs are also not in the desired sequence ...

Thanks again,

Roman