January. On Wed, Dec 19, 2018 at 2:04 AM S G <[email protected]> wrote:
> It would be nice to see Solr 8 in January soon as there is an enhancement > on nested-documents we are waiting to get our hands on. > Any idea when Solr 8 would be out ? > > Thx > SG > > On Mon, Dec 17, 2018 at 1:34 PM David Smiley <[email protected]> > wrote: > >> I see 10 JIRA issues matching this filter: project in (SOLR, LUCENE) >> AND priority = Blocker and status = open and fixVersion = "master (8.0)" >> click here: >> >> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20 >> >> Thru the end of the month, I intend to work on those issues not yet >> assigned. >> >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <[email protected]> wrote: >> >>> +1 >>> >>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <[email protected]> >>> wrote: >>> > >>> > Hi all, >>> > >>> > Now that 7.6 is out of the door (thanks Nick!) we should think about >>> cutting the 8.0 branch and moving master to 9.0. I’ll volunteer to create >>> the branch this week - say Wednesday? Then we should have some time to >>> clean up the master branch and uncover anything that still needs to be done >>> on 8.0 before we start the release process next year. >>> > >>> > On 22 Oct 2018, at 18:12, Cassandra Targett <[email protected]> >>> wrote: >>> > >>> > I'm a bit delayed, but +1 on the 7.6 and 8.0 plan from me too. >>> > >>> > On Fri, Oct 19, 2018 at 7:18 AM Erick Erickson < >>> [email protected]> wrote: >>> >> >>> >> +1, this gives us all a chance to prioritize getting the blockers out >>> >> of the way in a careful manner. >>> >> On Fri, Oct 19, 2018 at 7:56 AM jim ferenczi <[email protected]> >>> wrote: >>> >> > >>> >> > +1 too. With this new perspective we could create the branch just >>> after the 7.6 release and target the 8.0 release for January 2019 which >>> gives almost 3 month to finish the blockers ? >>> >> > >>> >> > Le jeu. 18 oct. 2018 à 23:56, David Smiley < >>> [email protected]> a écrit : >>> >> >> >>> >> >> +1 to a 7.6 —lots of stuff in there >>> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <[email protected]> >>> wrote: >>> >> >>> >>> >> >>> If we're planning to postpone cutting an 8.0 branch until a few >>> weeks from now then I'd like to propose (and volunteer to RM) a 7.6 release >>> targeted for late November or early December (following the typical 2 month >>> release pattern). It feels like this might give a little breathing room for >>> finishing up 8.0 blockers? And looking at the change log there appear to be >>> a healthy list of features, bug fixes, and improvements to both Solr and >>> Lucene that warrant a 7.6 release? Personally I wouldn't mind releasing the >>> LatLonShape encoding changes in LUCENE-8521 and selective indexing work >>> done in LUCENE-8496. Any objections or thoughts? >>> >> >>> >>> >> >>> - Nick >>> >> >>> >>> >> >>> >>> >> >>> On Thu, Oct 18, 2018 at 5:32 AM Đạt Cao Mạnh < >>> [email protected]> wrote: >>> >> >>>> >>> >> >>>> Thanks Cassandra and Jim, >>> >> >>>> >>> >> >>>> I created a blocker issue for Solr 8.0 SOLR-12883, currently in >>> jira/http2 branch there are a draft-unmature implementation of SPNEGO >>> authentication which enough to makes the test pass, this implementation >>> will be removed when SOLR-12883 gets resolved . Therefore I don't see any >>> problem on merging jira/http2 to master branch in the next week. >>> >> >>>> >>> >> >>>> On Thu, Oct 18, 2018 at 2:33 AM jim ferenczi < >>> [email protected]> wrote: >>> >> >>>>> >>> >> >>>>> > But if you're working with a different assumption - that just >>> the existence of the branch does not stop Dat from still merging his work >>> and the work being included in 8.0 - then I agree, waiting for him to merge >>> doesn't need to stop the creation of the branch. >>> >> >>>>> >>> >> >>>>> Yes that's my reasoning. This issue is a blocker so we won't >>> release without it but we can work on the branch in the meantime and let >>> other people work on new features that are not targeted to 8. >>> >> >>>>> >>> >> >>>>> Le mer. 17 oct. 2018 à 20:51, Cassandra Targett < >>> [email protected]> a écrit : >>> >> >>>>>> >>> >> >>>>>> OK - I was making an assumption that the timeline for the >>> first 8.0 RC would be ASAP after the branch is created. >>> >> >>>>>> >>> >> >>>>>> It's a common perception that making a branch freezes adding >>> new features to the release, perhaps in an unofficial way (more of a >>> courtesy rather than a rule). But if you're working with a different >>> assumption - that just the existence of the branch does not stop Dat from >>> still merging his work and the work being included in 8.0 - then I agree, >>> waiting for him to merge doesn't need to stop the creation of the branch. >>> >> >>>>>> >>> >> >>>>>> If, however, once the branch is there people object to Dat >>> merging his work because it's "too late", then the branch shouldn't be >>> created yet because we want to really try to clear that blocker for 8.0. >>> >> >>>>>> >>> >> >>>>>> Cassandra >>> >> >>>>>> >>> >> >>>>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi < >>> [email protected]> wrote: >>> >> >>>>>>> >>> >> >>>>>>> Ok thanks for answering. >>> >> >>>>>>> >>> >> >>>>>>> > - I think Solr needs a couple more weeks since the work Dat >>> is doing isn't quite done yet. >>> >> >>>>>>> >>> >> >>>>>>> We can wait a few more weeks to create the branch but I don't >>> think that one action (creating the branch) prevents the other (the work >>> Dat is doing). >>> >> >>>>>>> HTTP/2 is one of the blocker for the release but it can be >>> done in master and backported to the appropriate branch as any other >>> feature ? We just need an issue with the blocker label to ensure that >>> >> >>>>>>> we don't miss it ;). Creating the branch early would also >>> help in case you don't want to release all the work at once in 8.0.0. >>> >> >>>>>>> Next week was just a proposal, what I meant was soon because >>> we target a release in a few months. >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett < >>> [email protected]> a écrit : >>> >> >>>>>>>> >>> >> >>>>>>>> IMO next week is a bit too soon for the branch - I think >>> Solr needs a couple more weeks since the work Dat is doing isn't quite done >>> yet. >>> >> >>>>>>>> >>> >> >>>>>>>> Solr needs the HTTP/2 work Dat has been doing, and he told >>> me yesterday he feels it is nearly ready to be merged into master. However, >>> it does require a new release of Jetty to Solr is able to retain Kerberos >>> authentication support (Dat has been working with that team to help test >>> the changes Jetty needs to support Kerberos with HTTP/2). They should get >>> that release out soon, but we are dependent on them a little bit. >>> >> >>>>>>>> >>> >> >>>>>>>> He can hopefully reply with more details on his status and >>> what else needs to be done. >>> >> >>>>>>>> >>> >> >>>>>>>> Once Dat merges his work, IMO we should leave it in master >>> for a little bit. While he has been beasting and testing with Jenkins as he >>> goes along, I think it would be good to have all the regular master builds >>> work on it for a little bit also. >>> >> >>>>>>>> >>> >> >>>>>>>> Of the other blockers, the only other large-ish one is to >>> fully remove Trie* fields, which some of us also discussed yesterday and it >>> seemed we concluded that Solr isn't really ready to do that. The >>> performance issues with single value lookups are a major obstacle. It would >>> be nice if someone with a bit more experience with that could comment in >>> the issue (SOLR-12632) and/or unmark it as a blocker. >>> >> >>>>>>>> >>> >> >>>>>>>> Cassandra >>> >> >>>>>>>> >>> >> >>>>>>>> On Wed, Oct 17, 2018 at 8:38 AM Erick Erickson < >>> [email protected]> wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>> I find 9 open blockers for 8.0: >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN >>> >> >>>>>>>>> >>> >> >>>>>>>>> As David mentioned, many of the SOlr committers are at >>> Activate, which >>> >> >>>>>>>>> ends Thursday so feedback (and work) may be a bit delayed. >>> >> >>>>>>>>> On Wed, Oct 17, 2018 at 8:11 AM David Smiley < >>> [email protected]> wrote: >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > Hi, >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > Thanks for volunteering to do the 8.0 release Jim! >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > Many of us are at the Activate Conference in Montreal. >>> We had a committers meeting where we discussed some of the blockers. I >>> think only a couple items were raised. I'll leave Dat to discuss the one >>> on HTTP2. On the Solr nested docs front, I articulated one and we mostly >>> came to a decision on how to do it. It's not "hard" just a matter of how >>> to hook in some functionality so that it's user-friendly. I'll file an >>> issue for this. Inexplicably I'm sheepish about marking issues "blocker" >>> but I shouldn't be. I'll file that issue and look at another issue or two >>> that ought to be blockers. Nothing is "hard" or tons of work that is in my >>> sphere of work. >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > On the Lucene side, I will commit >>> https://issues.apache.org/jira/browse/LUCENE-7875 RE MultiFields either >>> late tonight or tomorrow when I have time. It's ready to be committed; >>> just sitting there. It's a minor thing but important to make this change >>> now before 8.0. >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > I personally plan to spend more time on the upcoming >>> weeks on a few of these 8.0 things. >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > ~ David >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > On Wed, Oct 17, 2018 at 4:21 AM jim ferenczi < >>> [email protected]> wrote: >>> >> >>>>>>>>> >> >>> >> >>>>>>>>> >> Hi, >>> >> >>>>>>>>> >> We still have two blockers for the Lucene 8 release: >>> >> >>>>>>>>> >> >>> https://issues.apache.org/jira/browse/LUCENE-7075?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocker%20and%20resolution%20%3D%20Unresolved%20 >>> >> >>>>>>>>> >> We're planning to work on these issues in the coming >>> days, are there any other blockers (not in the list) on Solr side. >>> >> >>>>>>>>> >> Now that Lucene 7.5 is released I'd like to create a >>> Lucene 8 branch soon (next week for instance ? ). There are some work to do >>> to make sure that all tests pass, add the new version... >>> >> >>>>>>>>> >> I can take care of it if there are no objections. >>> Creating the branch in advance would help to stabilize this version (people >>> can continue to work on new features that are not targeted for 8.0) and >>> >> >>>>>>>>> >> we can discuss the best date for the release when all >>> blockers are resolved. What do you think ? >>> >> >>>>>>>>> >> >>> >> >>>>>>>>> >> >>> >> >>>>>>>>> >> >>> >> >>>>>>>>> >> Le mar. 18 sept. 2018 à 11:32, Adrien Grand < >>> [email protected]> a écrit : >>> >> >>>>>>>>> >>> >>> >> >>>>>>>>> >>> Đạt, is >>> https://issues.apache.org/jira/browse/SOLR-12639 the right issue for >>> HTTP/2 support? Should we make it a blocker for 8.0? >>> >> >>>>>>>>> >>> >>> >> >>>>>>>>> >>> Le lun. 3 sept. 2018 à 23:37, Adrien Grand < >>> [email protected]> a écrit : >>> >> >>>>>>>>> >>>> >>> >> >>>>>>>>> >>>> For the record here is the JIRA query for blockers >>> that Erick referred to: >>> https://issues.apache.org/jira/browse/SOLR-12720?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocker%20and%20resolution%20%3D%20Unresolved%20 >>> >> >>>>>>>>> >>>> >>> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi < >>> [email protected]> a écrit : >>> >> >>>>>>>>> >>>>> >>> >> >>>>>>>>> >>>>> Ok thanks Đạt and Erick. I'll follow the blockers on >>> Jira. Đạt do you have an issue opened for the HTTP/2 support ? >>> >> >>>>>>>>> >>>>> >>> >> >>>>>>>>> >>>>> Le ven. 31 août 2018 à 16:40, Erick Erickson < >>> [email protected]> a écrit : >>> >> >>>>>>>>> >>>>>> >>> >> >>>>>>>>> >>>>>> There's also the issue of what to do as far as >>> removing Trie* support. >>> >> >>>>>>>>> >>>>>> I think there's a blocker JIRA. >>> >> >>>>>>>>> >>>>>> >>> >> >>>>>>>>> >>>>>> project = SOLR AND priority = Blocker AND resolution >>> = Unresolved >>> >> >>>>>>>>> >>>>>> >>> >> >>>>>>>>> >>>>>> Shows 6 blockers >>> >> >>>>>>>>> >>>>>> On Fri, Aug 31, 2018 at 4:12 AM Đạt Cao Mạnh < >>> [email protected]> wrote: >>> >> >>>>>>>>> >>>>>> > >>> >> >>>>>>>>> >>>>>> > Hi Jim, >>> >> >>>>>>>>> >>>>>> > >>> >> >>>>>>>>> >>>>>> > I really want to introduce the support of HTTP/2 >>> into Solr 8.0 (currently cooked in jira/http2 branch). The changes of that >>> branch are less than Star Burst effort and closer to be merged into master >>> branch. >>> >> >>>>>>>>> >>>>>> > >>> >> >>>>>>>>> >>>>>> > Thanks! >>> >> >>>>>>>>> >>>>>> > >>> >> >>>>>>>>> >>>>>> > On Fri, Aug 31, 2018 at 3:55 PM jim ferenczi < >>> [email protected]> wrote: >>> >> >>>>>>>>> >>>>>> >> >>> >> >>>>>>>>> >>>>>> >> Hi all, >>> >> >>>>>>>>> >>>>>> >> I'd like to get some feedback regarding the >>> upcoming Lucene/Solr 8 release. There are still some cleanups and docs to >>> add on the Lucene side but it seems that all blockers are resolved. >>> >> >>>>>>>>> >>>>>> >> From a Solr perspective are there any important >>> changes that need to be done or are we still good with the October target >>> for the release ? Adrien mentioned the Star Burst effort some time ago, is >>> it something that is planned for 8 ? >>> >> >>>>>>>>> >>>>>> >> >>> >> >>>>>>>>> >>>>>> >> Cheers, >>> >> >>>>>>>>> >>>>>> >> Jim >>> >> >>>>>>>>> >>>>>> >> >>> >> >>>>>>>>> >>>>>> >> Le mer. 1 août 2018 à 19:02, David Smiley < >>> [email protected]> a écrit : >>> >> >>>>>>>>> >>>>>> >>> >>> >> >>>>>>>>> >>>>>> >>> Yes, that new BKD/Points based code is >>> definitely something we want in 8 or 7.5 -- it's a big deal. I think it >>> would also be awesome if we had highlighter that could use the >>> Weight.matches() API -- again for either 7.5 or 8. I'm working on this on >>> the UnifiedHighlighter front and Alan from other aspects. >>> >> >>>>>>>>> >>>>>> >>> ~ David >>> >> >>>>>>>>> >>>>>> >>> >>> >> >>>>>>>>> >>>>>> >>> On Wed, Aug 1, 2018 at 12:51 PM Adrien Grand < >>> [email protected]> wrote: >>> >> >>>>>>>>> >>>>>> >>>> >>> >> >>>>>>>>> >>>>>> >>>> I was hoping that we would release some bits of >>> this new support for geo shapes in 7.5 already. We are already very close >>> to being able to index points, lines and polygons and query for >>> intersection with an envelope. It would be nice to add support for other >>> relations (eg. disjoint) and queries (eg. polygon) but the current work >>> looks already useful to me. >>> >> >>>>>>>>> >>>>>> >>>> >>> >> >>>>>>>>> >>>>>> >>>> Le mer. 1 août 2018 à 17:00, Robert Muir < >>> [email protected]> a écrit : >>> >> >>>>>>>>> >>>>>> >>>>> >>> >> >>>>>>>>> >>>>>> >>>>> My only other suggestion is we may want to get >>> Nick's shape stuff into >>> >> >>>>>>>>> >>>>>> >>>>> the sandbox module at least for 8.0 so that it >>> can be tested out. I >>> >> >>>>>>>>> >>>>>> >>>>> think it looks like that wouldn't delay any >>> October target though? >>> >> >>>>>>>>> >>>>>> >>>>> >>> >> >>>>>>>>> >>>>>> >>>>> On Wed, Aug 1, 2018 at 9:51 AM, Adrien Grand < >>> [email protected]> wrote: >>> >> >>>>>>>>> >>>>>> >>>>> > I'd like to revive this thread now that >>> these new optimizations for >>> >> >>>>>>>>> >>>>>> >>>>> > collection of top docs are more usable and >>> enabled by default in >>> >> >>>>>>>>> >>>>>> >>>>> > IndexSearcher ( >>> https://issues.apache.org/jira/browse/LUCENE-8060). Any >>> >> >>>>>>>>> >>>>>> >>>>> > feedback about starting to work towards >>> releasing 8.0 and targeting October >>> >> >>>>>>>>> >>>>>> >>>>> > 2018? >>> >> >>>>>>>>> >>>>>> >>>>> > >>> >> >>>>>>>>> >>>>>> >>>>> > >>> >> >>>>>>>>> >>>>>> >>>>> > Le jeu. 21 juin 2018 à 09:31, Adrien Grand < >>> [email protected]> a écrit : >>> >> >>>>>>>>> >>>>>> >>>>> >> >>> >> >>>>>>>>> >>>>>> >>>>> >> Hi Robert, >>> >> >>>>>>>>> >>>>>> >>>>> >> >>> >> >>>>>>>>> >>>>>> >>>>> >> I agree we need to make it more usable >>> before 8.0. I would also like to >>> >> >>>>>>>>> >>>>>> >>>>> >> improve ReqOptSumScorer ( >>> https://issues.apache.org/jira/browse/LUCENE-8204) >>> >> >>>>>>>>> >>>>>> >>>>> >> to leverage impacts so that queries that >>> incorporate queries on feature >>> >> >>>>>>>>> >>>>>> >>>>> >> fields ( >>> https://issues.apache.org/jira/browse/LUCENE-8197) in an optional >>> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast. >>> >> >>>>>>>>> >>>>>> >>>>> >> >>> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir < >>> [email protected]> a écrit : >>> >> >>>>>>>>> >>>>>> >>>>> >>> >>> >> >>>>>>>>> >>>>>> >>>>> >>> How can the end user actually use the >>> biggest new feature: impacts and >>> >> >>>>>>>>> >>>>>> >>>>> >>> BMW? As far as I can tell, the issue to >>> actually implement the >>> >> >>>>>>>>> >>>>>> >>>>> >>> necessary API changes >>> (IndexSearcher/TopDocs/etc) is still open and >>> >> >>>>>>>>> >>>>>> >>>>> >>> unresolved, although there are some >>> interesting ideas on it. This >>> >> >>>>>>>>> >>>>>> >>>>> >>> seems like a really big missing piece, >>> without a proper API, the stuff >>> >> >>>>>>>>> >>>>>> >>>>> >>> is not really usable. I also can't imagine >>> a situation where the API >>> >> >>>>>>>>> >>>>>> >>>>> >>> could be introduced in a followup minor >>> release because it would be >>> >> >>>>>>>>> >>>>>> >>>>> >>> too invasive. >>> >> >>>>>>>>> >>>>>> >>>>> >>> >>> >> >>>>>>>>> >>>>>> >>>>> >>> On Mon, Jun 18, 2018 at 1:19 PM, Adrien >>> Grand <[email protected]> wrote: >>> >> >>>>>>>>> >>>>>> >>>>> >>> > Hi all, >>> >> >>>>>>>>> >>>>>> >>>>> >>> > >>> >> >>>>>>>>> >>>>>> >>>>> >>> > I would like to start discussing >>> releasing Lucene/Solr 8.0. Lucene 8 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > already >>> >> >>>>>>>>> >>>>>> >>>>> >>> > has some good changes around scoring, >>> notably cleanups to >>> >> >>>>>>>>> >>>>>> >>>>> >>> > similarities[1][2][3], indexing of >>> impacts[4], and an implementation of >>> >> >>>>>>>>> >>>>>> >>>>> >>> > Block-Max WAND[5] which, once combined, >>> allow to run queries faster >>> >> >>>>>>>>> >>>>>> >>>>> >>> > when >>> >> >>>>>>>>> >>>>>> >>>>> >>> > total hit counts are not requested. >>> >> >>>>>>>>> >>>>>> >>>>> >>> > >>> >> >>>>>>>>> >>>>>> >>>>> >>> > [1] >>> https://issues.apache.org/jira/browse/LUCENE-8116 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > [2] >>> https://issues.apache.org/jira/browse/LUCENE-8020 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > [3] >>> https://issues.apache.org/jira/browse/LUCENE-8007 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > [4] >>> https://issues.apache.org/jira/browse/LUCENE-4198 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > [5] >>> https://issues.apache.org/jira/browse/LUCENE-8135 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > >>> >> >>>>>>>>> >>>>>> >>>>> >>> > In terms of bug fixes, there is also a >>> bad relevancy bug[6] which is >>> >> >>>>>>>>> >>>>>> >>>>> >>> > only in >>> >> >>>>>>>>> >>>>>> >>>>> >>> > 8.0 because it required a breaking >>> change[7] to be implemented. >>> >> >>>>>>>>> >>>>>> >>>>> >>> > >>> >> >>>>>>>>> >>>>>> >>>>> >>> > [6] >>> https://issues.apache.org/jira/browse/LUCENE-8031 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > [7] >>> https://issues.apache.org/jira/browse/LUCENE-8134 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > >>> >> >>>>>>>>> >>>>>> >>>>> >>> > As usual, doing a new major release will >>> also help age out old codecs, >>> >> >>>>>>>>> >>>>>> >>>>> >>> > which >>> >> >>>>>>>>> >>>>>> >>>>> >>> > in-turn make maintenance easier: 8.0 >>> will no longer need to care about >>> >> >>>>>>>>> >>>>>> >>>>> >>> > the >>> >> >>>>>>>>> >>>>>> >>>>> >>> > fact that some codecs were initially >>> implemented with a random-access >>> >> >>>>>>>>> >>>>>> >>>>> >>> > API >>> >> >>>>>>>>> >>>>>> >>>>> >>> > for doc values, that pre-7.0 indices >>> encoded norms differently, or that >>> >> >>>>>>>>> >>>>>> >>>>> >>> > pre-6.2 indices could not record an >>> index sort. >>> >> >>>>>>>>> >>>>>> >>>>> >>> > >>> >> >>>>>>>>> >>>>>> >>>>> >>> > I also expect that we will come up with >>> ideas of things to do for 8.0 >>> >> >>>>>>>>> >>>>>> >>>>> >>> > as we >>> >> >>>>>>>>> >>>>>> >>>>> >>> > feel that the next major is getting >>> closer. In terms of planning, I was >>> >> >>>>>>>>> >>>>>> >>>>> >>> > thinking that we could target something >>> like october 2018, which would >>> >> >>>>>>>>> >>>>>> >>>>> >>> > be >>> >> >>>>>>>>> >>>>>> >>>>> >>> > 12-13 months after 7.0 and 3-4 months >>> from now. >>> >> >>>>>>>>> >>>>>> >>>>> >>> > >>> >> >>>>>>>>> >>>>>> >>>>> >>> > From a Solr perspective, the main change >>> I'm aware of that would be >>> >> >>>>>>>>> >>>>>> >>>>> >>> > worth >>> >> >>>>>>>>> >>>>>> >>>>> >>> > releasing a new major is the Star Burst >>> effort. Is it something we want >>> >> >>>>>>>>> >>>>>> >>>>> >>> > to >>> >> >>>>>>>>> >>>>>> >>>>> >>> > get in for 8.0? >>> >> >>>>>>>>> >>>>>> >>>>> >>> > >>> >> >>>>>>>>> >>>>>> >>>>> >>> > Adrien >>> >> >>>>>>>>> >>>>>> >>>>> >>> >>> >> >>>>>>>>> >>>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> >> >>>>>>>>> >>>>>> >>>>> >>> 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] >>> >> >>>>>>>>> >>>>>> >>>>> >>> >> >>>>>>>>> >>>>>> >>> -- >>> >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, >>> Developer, Author, Speaker >>> >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley | >>> Book: http://www.solrenterprisesearchserver.com >>> >> >>>>>>>>> >>>>>> >>> >> >>>>>>>>> >>>>>> >>> --------------------------------------------------------------------- >>> >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: >>> [email protected] >>> >> >>>>>>>>> >>>>>> For additional commands, e-mail: >>> [email protected] >>> >> >>>>>>>>> >>>>>> >>> >> >>>>>>>>> > -- >>> >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, >>> Author, Speaker >>> >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>> http://www.solrenterprisesearchserver.com >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> --------------------------------------------------------------------- >>> >> >>>>>>>>> To unsubscribe, e-mail: [email protected] >>> >> >>>>>>>>> For additional commands, e-mail: [email protected] >>> >> >>>>>>>>> >>> >> >>> -- >>> >> >>> >>> >> >>> Nicholas Knize, Ph.D., GISP >>> >> >>> Geospatial Software Guy | Elasticsearch >>> >> >>> Apache Lucene Committer >>> >> >>> [email protected] >>> >> >> >>> >> >> -- >>> >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, >>> Speaker >>> >> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>> http://www.solrenterprisesearchserver.com >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> > >>> >>> >>> -- >>> Adrien >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> -- >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> http://www.solrenterprisesearchserver.com >> > -- Lucene/Solr Search Committer (PMC), Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
