Christine, Wow, that's fantastic. You can also pass a --grep argument to git directly.
Another problem that just occurred to me though, is that we might need to make updates to CHANGES files too. I'm not sure how to automate the check for that, since the format can be pretty messy. Mike On Thu, May 25, 2017 at 8:39 AM, Christine Poerschke (BLOOMBERG/ LONDON) < cpoersc...@bloomberg.net> wrote: > Hi Everyone, > > Perhaps a little more context would help get us all on the same page re: > the "to 6.x or to not 6.x" tag question. > > === "to 6.x" tag === > > So, some of us (myself included) for SOLR issues used to tag FixVersion > 6.x since the commit was to branch_6x and (at least myself) assumed that > when branch_6_7 is cut from branch_6x then the process would somehow > magically turn 6.x tags into 6.7 tags, and any subsequently added 6.x tags > become 6.8 in future etc. > > The 6.x to 6.7 transition would be an extra part of the release process > and if/since it isn't actually a part of the process then it's > retrospectively really really tedious to resolve 6.x to the correct > 6.something tag. > > === "to not 6.x" tag === > > An alternative is always tag to a specific (future) version i.e. to _not_ > 6.x tag anything and to let the released/unreleased categorisation take > care of the already-released vs. scheduled-to-be-released difference. > > === where we are now === > > There are still some tickets tagged to 6.x and people looking at the > version dropdown choices will see 6.x as an existing choice. If/When no > tickets are tagged to 6.x anymore then the 6.x choice could be removed from > the dropdown choices leaving only specific versions to choose from. > > Having said all that, turning existing 6.x tagging into specific versions > is tedious but not totally impossible, I did a few yesterday using simple > git grep lookups: > > 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 > > Hope that helps? What do people think? > > Christine > > From: dev@lucene.apache.org At: 05/25/17 14:08:37 > To: dev@lucene.apache.org, dawid.we...@gmail.com, jpou...@apache.org, > luc...@mikemccandless.com, kwri...@apache.org, u...@thetaphi.de > Subject: Re: Strange Solr JIRA versions (Lucene too!) > > Lucene devs, lets get on the same page about this issue. > > Dawid seems to _want_ to use 6.x > https://issues.apache.org/jira/browse/LUCENE-7841? > focusedCommentId=16024639&page=com.atlassian.jira. > plugin.system.issuetabpanels:comment-tabpanel#comment-16024639 > Christine and I are the only ones to have commented about this pertaining > to LUCENE JIRA issues. Lets have this conversation here, not on > LUCENE-7841. > > ~ David > > On Thu, May 25, 2017 at 1:28 AM David Smiley <david.w.smi...@gmail.com> > wrote: > >> Aha; this problem is a little more than a nuisance... it seems to be why >> most of these issues are marked Resolved and not Closed as well. The RM's >> release process is to search for JIRA issues with a fix version of the >> release version (i.e. 6.6 NOT 6.x). Issues that do not have a real version >> then fall through the cracks and remain in a "Resolved" limbo/ambiguity: >> https://issues.apache.org/jira/issues/?jql=project%20% >> 3D%20LUCENE%20AND%20status%20in%20(Resolved)%20AND% >> 20fixVersion%20%3D%206.x%20ORDER%20BY%20fixVersion% >> 20ASC%2C%20assignee%20ASC >> And thus it's unclear to users browsing these issues in JIRA for which >> version the issue was released in. >> >> ~ David >> >> >> On Wed, May 24, 2017 at 11:16 AM David Smiley <david.w.smi...@gmail.com> >> wrote: >> >>> 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 >>> >> -- >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www. >> solrenterprisesearchserver.com >> > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www. > solrenterprisesearchserver.com > >
