Bummer, seems we can't lock this down :( https://jira.atlassian.com/browse/JRASERVER-42068
On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[email protected]> wrote: > On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett <[email protected]> > 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. >> > > Ah, that makes this a lot less baffling I guess. > > >> >> 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. >> > > +1! > > >> >> 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. >> > > I agree. > > >> >> 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. >> > > +1. It also matches how we handle CHANGES afaict. > > I wish we could disable the auto creating of versions entirely somehow, > but I guess the next best thing is to raise awareness. It's great to have > the correct versions and in the correct ordering. > > - Mark > > >> >> 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 <[email protected]> >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- > - Mark > about.me/markrmiller > -- - Mark about.me/markrmiller
