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] >>>> >>>> >>
