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?
Project = FOO
Has Fix Version/s (in this order) = (188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199)
Would like to query for all issues with a Fix Version >= 188.8.131.52
Currently, in this example, if I ran a JQL query with "fixVersion > 184.108.40.206" it would return (220.127.116.11, 18.104.22.168, 22.214.171.124) when logically you would think it would only return 126.96.36.199 because those numbers are larger, HOWEVER JIRA instead looks at each version object's position in that Project's settings and since 188.8.131.52 and 184.108.40.206 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.
Community moderators have prevented the ability to post new answers.
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):
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 ...
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
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.
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.
Versions can easily be ordered from each JIRA project by drag&droping:
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.
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
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.
> 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.
That's the name of @Mike Cannon-Brookes's blog post about Atlassian's climate policy and support of the worldwide climate strike. I know some of you are attending strikes around the worl...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events