How would you find all numerically greater Fix Versions WITHOUT their order in the project settings mattering?

[Geoff Wilson]

Similar to other questions from 4 years ago (and hoping that maybe JQL has gotten more advanced since then), is there any way to query for all Fix Versions numerically greater than a specified one WITHOUT caring what order the versions are listed in in the Project's settings?

Ex:

Project = FOO

Has Fix Version/s (in this order) = (1.0.0.0, 1.0.1.0, 2.0.0.0, 1.1.0.0, 1.1.1.1, 2.0.1.0)

Would like to query for all issues with a Fix Version >= 2.0.0.0

Currently, in this example, if I ran a JQL query with "fixVersion > 2.0.0.0" it would return (1.1.0.0, 1.1.1.1, 2.0.1.0) when logically you would think it would only return 2.0.1.0 because those numbers are larger, HOWEVER JIRA instead looks at each version object's position in that Project's settings and since 1.1.0.0 and 1.1.1.1 are higher in the list (because new versions get created at the top of the list by default) then they are returned with the > query. 

Even if we did this example with simpler numbers sans decimal points like 1000, 1010, 2000, 1100, 1111, 2010 we'd still get the same 3 version numbers returned when this doesn't seem logically correct at all.  This may also be related to this invalidated 'bug' even though I think that person was seeing roughly the same situation that I am.  These are critical to querying issues for Delivery Opportunity quality metric reports (of how many versions have been released since the defect was found).

Side note: regarding the solution I'm really looking for of how many software deliveries have been completed since an unresolved defect was created, I currently tried comparing dates of defect Created date against software delivery issue Due date, which only works if there are no previous version re-deliveries for fixes after the newer version's defect was created.

[Geoff Wilson · Accepted solution]

I do have one programmatic solution of my own, but was hoping that in some way there'd be a way to query this purely in JQL along with some trickery if necessary like through Scriptrunner or other JDK query tools. 

Using our own custom plugin we've had to write for JIRA as it is to accomplish the reports that we desire, we could try the following (in JAVA, but using a JQL query in the end):

1. Find all version numbers in a Project
2. For each version number (that will always be in the format of x.x.x.x*):
   
   1. compare the first number value (up until the first . period is found) against the input version number's first value to see if
      
      1. if higher, store this version number in a new list of good numbers and skip to the next version number in the version's list
      2. if equal, move onto the next value after the . period and repeat this comparison until reaching the last value which will have no . period after it
         1. If still equal, then can decide if want to add it to the new list or ignore it, depending on if you want > or >=
      3. if lower, ignore this version number as it is not greater than the given version number
3. Take the final new list of acceptable version numbers as being the list of all versions that are in fact greater than the given version number
4. Supply this list of numbers in a JQL query of "fixVersion in (list of greater versions)" which will give you what logically would make sense as fixVersion >= 2.0.0.0 in my original example

[Geoff Wilson]

In analyzing this concept though, I did find that this would potentially also lead to an exponential amount of processing as more and more versions are added per project that need to be compared. While it's do-able, there is a high level of complexity here in parsing and analyzing version numbers that meet this format (and also those that may deviate with alphabetic characters and such).

Perhaps we do bite the usability psychological bullet and do try to enforce recall training to hold Leads accountable for keeping their version numbers in a numerically incremental order ...

[Geoff Wilson]

Selecting my own just to have this marked as answered, but I would like to give credit to all others too.  There are so many stipulations I've found in this problem.  While organizing versions in the project's settings does allow the use of the greaterThan, lessThan, etc operators, those do not work as far as I can tell if someone has selected 2+ affectedVersions or fixVersions. Also, as Jamie and I wrote, you may have wanted to organize your versions in a variety of different ways on purpose, but in my particular case, I need it by actual numbers. There are many, many solutions in java already existing for parsing and determining version number orders online, but those are based on a X.X.X schema and not what our group uses unfortunately (although, it could be tweaked). 

I'm still actually working on this problem, but at least the pseudo-concepts were laid out with all inherent risks of each

[Ignacio Pulgar]

The official docs specifically state:

Note that the comparison operators (e.g. ">") use the version order that has been set up by your project administrator, not a numeric or alphabetic order.

[Geoff Wilson]

Thanks for the doc specification, but we cannot rely on that solution as it fails in a usability evaluation. Project Leads will not have reminders available to them when looking at the Version administration screen to maintain a desired visual order of versions, so as we consider the "Recognition rather than recall" and "Error prevention" usability heuristics, we cannot rely on them to think of this need. It is not a need for them as they just want to quickly create a new version, and get on with their own tasking. It is a QA and metrics need that these version calculations be performed, not a lead's so their mental motivation is different.

[Ignacio Pulgar]

As a workaround, you may create a numeric custom field, and assign a value to each version as per your needs. You can search for a specific fixVersion, and give a value to all those issues at once through a bulk edit operation. After that, you will be able of using comparators in the way you need.

[Ignacio Pulgar]

Versions can easily be ordered from each JIRA project by drag&droping:

https://<YOURS>.atlassian.net/plugins/servlet/project-config/<FOO>/administer-versions

It just requires Administer Projects permission, which is typically (by default) granted to users with Administrators project role.

Given that versions may have different structures, even arbitrary strings, like pokemon names (really!), the simplest solution would be asking project Administrators to keep their project versions in the correct order so that comparators work as desired.

[JamieA]

I would have suggested doing more or less what you said Geoff, in ScriptRunner as a jql function, if you have the plugin. But it's easier for end users to just do it for all versions, and forget the project. Happy to help with this tomorrow.

All of 2) ca be accomplished by some off-the-shelf code.

You would end up running JQL like: fixVersion in greaterThanByVersionName("1.0.0")

But you would also want a "less than" equivalent.

> The official docs specifically state

They do say that, but it doesn't make it useful. There are different ways of ordering versions, for me what makes the most sense is the release date, for Geoff it's the identifier, for other people it's the start date or the sequence.

 > because new versions get created at the top of the list by default) then they are returned with the > query

True, but it doesn't really make sense to me why v2 is created as a version before v1. Generally this works in the expected way, apart from when you need to do unexpected patch releases.

> regarding the solution I'm really looking for of how many software deliveries have been completed since an unresolved defect was created

As I said, happy to help further, but I don't really see how the proposed solution helps accomplish this. What you will get is some list of issues, rather than a list of versions. Even once you have the list, it's not easy to see what you asked for above.

Might be easier to just have a scripted field, that shows the list of versions after (by your comparison method) the current issue was created.

> newer or greater

Which? If you care about newer, you could use one of the new version functions in SR: https://scriptrunner.adaptavist.com/4.3.13/jira/jql-functions.html#_versions

[Geoff Wilson]

Updated the title and description to mean "numerically greater" because, like you also said, while most often this is the newest version number, it may not always be the newest (e.g. hot fix for old version in maintenance).

But now overall as I commented on my own answer ... while it's not a usability-successful solution by any means, relying on training and metaphorically slapping wrists to make sure people maintain their versions in the "right" numerical order, perhaps that user-forced solution is the best due to budget and time complexity needed to create a script to do this as well as for this script report to run (as more and more versions will be added to the system which will therefore need to get compounded and compared).  Just found out by looking at all 1000+ SW deliveries in our system across 300+ products that we do have a version-control variance of at least 28 different ways people have entered version numbers :/ Even if only say 5% of these are outliers, trying to parse and deal with each of those is complex in its own right. 

[JamieA]

> lead to an exponential

Linear, surely. But comparing version strings is a solved problem, I'd be surprised if 100k versions could not be done sub-second.

> 28 different ways people have entered version numbers

that's a problem. Try to get people to use sem ver. Unfortunately you cannot validate a version string, IIRC.

Anyway, I think you are probably right to keep it simple.