Also, this is entirely up to you guys, I can adjust to not using 6.x -- like I said, I've had those type of discussions before and am used to multiple ways of managing version tickets.
Dawid On Thu, May 25, 2017 at 8:08 PM, Cassandra Targett <casstarg...@gmail.com> wrote: > There is an API in JIRA to create and update versions. Here are the > docs for it for the current version we're using: > https://docs.atlassian.com/jira/REST/6.3.15/#d2e3054. > > Scroll down for other endpoints that might be helpful - one of them is > to get the list of unreleased issues for a particular version. > > I've been able to use other issue-related API endpoints with my ASF > JIRA login and I assume that would be true here also, but not sure > about it. > > > On Thu, May 25, 2017 at 11:43 AM, Dawid Weiss <dawid.we...@gmail.com> wrote: >> I don't think it can be automated -- it'd require those few manual >> clicks in Jira. I am not a Jira expert though, perhaps it has an API >> that does make it scriptable. >> >> Dawid >> >> On Thu, May 25, 2017 at 6:23 PM, Erick Erickson <erickerick...@gmail.com> >> wrote: >>> Dawid: >>> >>> So can we automate this somehow? It's still extra work for the RM and >>> if it could become a one-liner addition to the release process maybe >>> we can make it easier. >>> >>> On Thu, May 25, 2017 at 8:42 AM, Dawid Weiss <dawid.we...@gmail.com> wrote: >>>> It's not really about wanting to tag it 6.x... It's something I got >>>> used to very much and something that helps (me) manage which >>>> branch(es) a given issue has been applied to. When 6.x tag is much >>>> like "next release cut from 6.x". When doing a release 6.[next] I'd >>>> grep for 6.x and bulk-add 6.[next] to all issues currently having 6.x, >>>> then remove 6.x from them (so that they have a constant fix-for, no >>>> branch included anymore). >>>> >>>> This process isn't the only one possible and I've had some discussions >>>> about alternative workflows. I didn't manage to convince my >>>> conversation partners and they failed to convince me, so I think it's >>>> a matter of personal preference. >>>> >>>> The ultimate reference is the changes.txt file anyway (?). >>>> >>>> Dawid >>>> >>>> On Thu, May 25, 2017 at 5:24 PM, 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 >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
