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]
