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
