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