Thanks for flagging this up! I've gone and tidied up a few (but not all) using a very unsophisticated git grep approach to determine the fix version.
what=LUCENE-NNNN for version in 0 1 2 3 4 5 6 ; do echo branch_6_$version git log --decorate --oneline --graph origin/branch_6_$version | grep $what done From: dev@lucene.apache.org At: 05/24/17 16:17:32 To: dev@lucene.apache.org Subject: Re: Strange Solr JIRA versions (Lucene too!) It seems this issue applies to Lucene too, and it's more widespread (79 issues): https://issues.apache.org/jira/issues/?jql=project%20%3D%20LUCENE%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%20branch_6x) On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett <casstarg...@gmail.com> wrote: I noticed these the other day also, and had an email half-wrote that I intended to finish up today. To start, JIRA unfortunately makes this really easy to make a mess of - if you can create or edit an issue, you can just pop in a new value that gets added to the list of open versions. Editing an issue is open to lots of folks - committers, contributors, the reporter of an issue. So, we have high potential for this to be an ongoing problem. But, since only committers can commit patches and are thus the usual resolvers of an issue, committers either aren't paying enough attention to that field when they resolve an issue or there is confusion/difference of understanding about what that field is supposed to mean. There are currently 49 issues for Solr that have these "non-standard" versions [1]. Some date back before the most recent 6.5.0 release, which means there are issues fixed in 6.4 and 6.5 (at least) which don't say so in JIRA. This could be really problematic going forward. We need to agree that when issues are resolved, the fixVersion field is reliable and means the same thing to everyone. IMO we should always use the *next* version that makes sense at that time. So, an issue resolved today would be "6.6" and "master (7.0)". Others may have different points of view on how we should do this, but I think traditionally it's been the way I suggest, so if there is change desired there, we should discuss it. Side note: I know there is some doubt today that 6.6 will ever exist. However, it will be a lot easier to go through JIRA to remove "6.6" from issues that aren't in 6.x than it will be to review issue-by-issue everything that says "6x" or "6.x" or "branch_6x", etc., and figure out when it was actually released. Cassandra [1] Query for JIRA issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x) On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller <markrmil...@gmail.com> wrote: > Who keeps adding strange JIRA release versions? I've cleaned up strange ones > in the past and they keep coming back. > > Why do we have branch6x, 6x and 6.x and trunk? > > Even if we wanted more than 6.1, 6.2, 6.2.1 and master (7.0), and I don't > think we do, who keeps adding these duplicates? Let's come to some sanity > here. > > - Mark > -- > - Mark > about.me/markrmiller --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com