Using x for a fix version is a pain for those of us dealing with multiple clients, even though I'm probably guilty of that sometime. My job often requires that I tell a client whether a particular fix is in a particular version of Lucene/Solr or not. Having to take the extra step of going from a JIRA found by searching to the CHANGES.txt file to find out that "For SOLR-xxx, 6x was really 6.4.2" is a pain. And that assumes that the JIRA was _entered_ in CHANGES.txt correctly. I know I've mis-typed a JIRA number in CHANGES.txt a time or two.
It's vastly easier to see Fix Version: 6.7 even if 6.7 hasn't been released. I know that without having to look anything up. Christine's comments about asking the RM to update all of the tickets marked with an "x" is an alternative but I dont' think making extra work for the RM is reasonable when we can just get it right the first time. P.S. Mike: I don't think I've ever seen an "x" version in CHANGES.txt, so I don't think that's a problem. Could be wrong of course. On Thu, May 25, 2017 at 8:24 AM, Mike Drob <md...@apache.org> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
