Hi Trey, Thanks for the heads up, and I am completely with you in terms of releasing this with 7.0. I am fine with you getting this in post branch creation so I'll go ahead and create the branch later in the day today.
-Anshum On Sun, Jun 25, 2017 at 8:10 AM Trey Grainger <[email protected]> wrote: > Anshum, > > I'll be working on what I hope is a final patch for SOLR-10494 (Change > default response format from xml to json) today. I expect to have it > uploaded in the late evening US time. It will still need to be reviewed and > (if acceptable) committed. It feels to me like the kind of change that > should only be made in a major release due to back-compat concerns. > > If this can make it in after the branch is created, then no problem, but > otherwise it might be worth waiting another day before branching. Up to you. > > -Trey > > On Sat, Jun 24, 2017 at 4:52 PM, Anshum Gupta <[email protected]> > wrote: > >> I'll create the 7x, and 7.0 branches *tomorrow*. >> >> Ishan, do you mean you would be able to close it by Tuesday? You would >> have to commit to both 7.0, and 7.x, in addition to master, but I think >> that should be ok. >> >> We also have SOLR-10803 open at this moment and we'd need to come to a >> decision on that as well in order to move forward with 7.0. >> >> P.S: If there are any objections to this plan, kindly let me know. >> >> -Anshum >> >> On Fri, Jun 23, 2017 at 5:03 AM Ishan Chattopadhyaya < >> [email protected]> wrote: >> >>> Hi Anshum, >>> >>> >>> > I will send out an email a day before cutting the branch, as well as >>> once the branch is in place. >>> I'm right now on travel, and unable to finish SOLR-10574 until Monday >>> (possibly Tuesday). >>> Regards, >>> Ishan >>> >>> On Tue, Jun 20, 2017 at 5:08 PM, Anshum Gupta <[email protected]> >>> wrote: >>> >>>> From my understanding, there's not really a 'plan' but some intention >>>> to release a 6.7 at some time if enough people need it, right? In that case >>>> I wouldn't hold back anything for a 6x line release and cut the 7x, and 7.0 >>>> branches around, but not before the coming weekend. I will send out an >>>> email a day before cutting the branch, as well as once the branch is in >>>> place. >>>> >>>> If anyone has any objections to that, do let me know. >>>> >>>> Once that happens, we'd have a feature freeze on the 7.0 branch but we >>>> can take our time to iron out the bugs. >>>> >>>> @Alan: Thanks for informing. I'll make sure that LUCENE-7877 is >>>> committed before I cut the branch. I have added the right fixVersion to the >>>> issue. >>>> >>>> -Anshum >>>> >>>> >>>> >>>> On Mon, Jun 19, 2017 at 8:33 AM Erick Erickson <[email protected]> >>>> wrote: >>>> >>>>> Anshum: >>>>> >>>>> I'm one of the people that expect a 6.7 release, but it's more along >>>>> the lines of setting expectations than having features I really want >>>>> to get in to the 6x code line. We nearly always have "just a few >>>>> things" that someone would like to put in, and/or a bug fix or two >>>>> that surfaces. >>>>> >>>>> I expect people to back-port stuff they consider easy/beneficial to >>>>> 6.x for "a while" as 7.0 solidifies, at their discretion of course. >>>>> Think of my position as giving people a target for tidying up 6.x >>>>> rather than a concrete plan ;). Just seems to always happen. >>>>> >>>>> And if there is no 6.7, that's OK too. Additions to master-2 usually >>>>> pretty swiftly stop as the hassle of merging any change into 3 code >>>>> lines causes people to pick what goes into master-2 more carefully ;) >>>>> >>>>> Erick >>>>> >>>>> On Mon, Jun 19, 2017 at 8:03 AM, Alan Woodward <[email protected]> >>>>> wrote: >>>>> > I’d like to get https://issues.apache.org/jira/browse/LUCENE-7877 >>>>> in for 7.0 >>>>> > - should be able to commit in the next couple of days. >>>>> > >>>>> > Alan Woodward >>>>> > www.flax.co.uk >>>>> > >>>>> > >>>>> > On 19 Jun 2017, at 15:45, Anshum Gupta <[email protected]> >>>>> wrote: >>>>> > >>>>> > Hi everyone, >>>>> > >>>>> > Here's the update about 7.0 release: >>>>> > >>>>> > There are still unresolved blockers for 7.0. >>>>> > Solr (12): >>>>> > >>>>> https://issues.apache.org/jira/browse/SOLR-6630?jql=project%20%3D%20Solr%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3D%20Blocker >>>>> > >>>>> > Lucene (None): >>>>> > >>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20%22Lucene%20-%20Core%22%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker >>>>> > >>>>> > Here are the ones that are unassigned: >>>>> > https://issues.apache.org/jira/browse/SOLR-6630 >>>>> > https://issues.apache.org/jira/browse/SOLR-10887 >>>>> > https://issues.apache.org/jira/browse/SOLR-10803 >>>>> > https://issues.apache.org/jira/browse/SOLR-10756 >>>>> > https://issues.apache.org/jira/browse/SOLR-10710 >>>>> > https://issues.apache.org/jira/browse/SOLR-9321 >>>>> > https://issues.apache.org/jira/browse/SOLR-8256 >>>>> > >>>>> > The ones that are already assigned, I'd request you to update the >>>>> JIRA so we >>>>> > can track it better. >>>>> > >>>>> > In addition, I am about to create another one as I wasn’t able to >>>>> extend >>>>> > SolrClient easily without a code duplication on master. >>>>> > >>>>> > This brings us to - 'when can we cut the branch'. I can create the >>>>> branch >>>>> > this week and we can continue to work on these as long as none of >>>>> these are >>>>> > 'new features' but I'd be happy to hear what everyone has to say. >>>>> > >>>>> > I know there were suggestions around a 6.7 release, does anyone who's >>>>> > interested in leading that have a timeline or an idea around what >>>>> features >>>>> > did you want in that release? If yes, I’d really want to wait until >>>>> at least >>>>> > the branch for 6.7 is cur for the purpose of easy back-compat >>>>> management and >>>>> > guarantee. >>>>> > >>>>> > Also, sorry for being on radio silence for the last few days. I’d >>>>> been >>>>> > traveling but now I’m back :). >>>>> > >>>>> > -Anshum Gupta >>>>> > >>>>> > On Sun, Jun 18, 2017 at 8:57 AM Dennis Gove <[email protected]> >>>>> wrote: >>>>> >> >>>>> >> I've committed the most critical changes I wanted to make. Please >>>>> don't >>>>> >> hold up on a v7 release on my part. >>>>> >> >>>>> >> Thanks! >>>>> >> >>>>> >> Dennis >>>>> >> >>>>> >> On Tue, Jun 13, 2017 at 9:27 AM, Dennis Gove <[email protected]> >>>>> wrote: >>>>> >>> >>>>> >>> Hi, >>>>> >>> >>>>> >>> I also have some cleanup I'd like to do prior to a cut of 7. There >>>>> are >>>>> >>> some new stream evaluators that I'm finding don't flow with the >>>>> general >>>>> >>> flavor of evaluators. I'm using >>>>> >>> https://issues.apache.org/jira/browse/SOLR-10882 for the cleanup, >>>>> but I do >>>>> >>> intend to be complete by June 16th. >>>>> >>> >>>>> >>> Thanks, >>>>> >>> Dennis >>>>> >>> >>>>> >>> >>>>> >>> On Sat, Jun 10, 2017 at 11:21 AM, Ishan Chattopadhyaya >>>>> >>> <[email protected]> wrote: >>>>> >>>> >>>>> >>>> Hi Anshum, >>>>> >>>> I would like to request you to consider delaying the branch >>>>> cutting by a >>>>> >>>> bit till we finalize the SOLR-10574 discussions and make the >>>>> changes. >>>>> >>>> Alternatively, we could backport the changes to that branch after >>>>> you cut >>>>> >>>> the branch now. >>>>> >>>> Regards, >>>>> >>>> Ishan >>>>> >>>> >>>>> >>>> On Sat, Jun 3, 2017 at 1:02 AM, Steve Rowe <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> > On Jun 2, 2017, at 5:40 PM, Shawn Heisey <[email protected]> >>>>> wrote: >>>>> >>>>> > >>>>> >>>>> > On 6/2/2017 10:23 AM, Steve Rowe wrote: >>>>> >>>>> > >>>>> >>>>> >> I see zero benefits from cutting branch_7x now. Shawn, can >>>>> you >>>>> >>>>> >> describe why you think we should do this? >>>>> >>>>> >> >>>>> >>>>> >> My interpretation of your argument is that you’re in favor of >>>>> >>>>> >> delaying cutting branch_7_0 until feature freeze - which BTW >>>>> is the status >>>>> >>>>> >> quo - but I don’t get why that argues for cutting branch_7x >>>>> now. >>>>> >>>>> > >>>>> >>>>> > I think I read something in the message I replied to that >>>>> wasn't >>>>> >>>>> > actually stated. I hate it when I don't read things closely >>>>> enough. >>>>> >>>>> > >>>>> >>>>> > I meant to address the idea of making both branch_7x and >>>>> branch_7_0 >>>>> >>>>> > at >>>>> >>>>> > the same time, whenever the branching happens. Somehow I came >>>>> up >>>>> >>>>> > with >>>>> >>>>> > the idea that the gist of the discussion included making the >>>>> branches >>>>> >>>>> > now, which I can see is not the case. >>>>> >>>>> > >>>>> >>>>> > My point, which I think applies equally to branch_7x, is to >>>>> wait as >>>>> >>>>> > long >>>>> >>>>> > as practical before creating a branch, so that there is as >>>>> little >>>>> >>>>> > backporting as we can manage, particularly minimizing the >>>>> amount of >>>>> >>>>> > time >>>>> >>>>> > that we have more than two branches being actively changed. >>>>> >>>>> >>>>> >>>>> +1 >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Steve >>>>> >>>>> www.lucidworks.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> To unsubscribe, e-mail: [email protected] >>>>> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>> >>>>> >>> >>>>> >> >>>>> > >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>> >
