I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <u...@thetaphi.de> wrote: > Cool, > > I am working on giving my best release time guess as possible on the > FOSDEM conference! > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > -----Original Message----- > > From: Adrien Grand <jpou...@gmail.com> > > Sent: Thursday, January 24, 2019 5:33 PM > > To: Lucene Dev <dev@lucene.apache.org> > > Subject: Re: Lucene/Solr 8.0 > > > > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th. > > > > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.feren...@gmail.com> > > wrote: > > > > > > Hi, > > > As we agreed some time ago I'd like to start on releasing 8.0. The > branch is > > already created so we can start the process anytime now. Unless there are > > objections I'd like to start the feature freeze next week in order to > build the > > first candidate the week after. > > > We'll also need a 7.7 release but I think we can handle both with Alan > so > > the question now is whether we are ok to start the release process or if > there > > are any blockers left ;). > > > > > > > > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseyg...@gmail.com> > > a écrit : > > >> > > >> I’ve started to work through the various deprecations on the new > master > > branch. There are a lot of them, and I’m going to need some assistance > for > > several of them, as it’s not entirely clear what to do. > > >> > > >> I’ll open two overarching issues in JIRA, one for lucene and one for > Solr, > > with lists of the deprecations that need to be removed in each one. > I’ll create > > a shared branch on gitbox to work against, and push the changes I’ve > already > > done there. We can then create individual JIRA issues for any changes > that > > are more involved than just deleting code. > > >> > > >> All assistance gratefully received, particularly for the Solr > deprecations > > where there’s a lot of code I’m unfamiliar with. > > >> > > >> On 8 Jan 2019, at 09:21, Alan Woodward <romseyg...@gmail.com> > > wrote: > > >> > > >> I think the current plan is to do a 7.7 release at the same time as > 8.0, to > > handle any last-minute deprecations etc. So let’s keep those jobs > enabled > > for now. > > >> > > >> On 8 Jan 2019, at 09:10, Uwe Schindler <u...@thetaphi.de> wrote: > > >> > > >> Hi, > > >> > > >> I will start and add the branch_8x jobs to Jenkins once I have some > time > > later today. > > >> > > >> The question: How to proceed with branch_7x? Should we stop using it > > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or > > are we planning to one more Lucene/Solr 7.7? In the latter case I would > keep > > the jenkins jobs enabled for a while. > > >> > > >> Uwe > > >> > > >> ----- > > >> Uwe Schindler > > >> Achterdiek 19, D-28357 Bremen > > >> http://www.thetaphi.de > > >> eMail: u...@thetaphi.de > > >> > > >> From: Alan Woodward <romseyg...@gmail.com> > > >> Sent: Monday, January 7, 2019 11:30 AM > > >> To: dev@lucene.apache.org > > >> Subject: Re: Lucene/Solr 8.0 > > >> > > >> OK, Christmas caught up with me a bit… I’ve just created a branch for > 8x > > from master, and am in the process of updating the master branch to > version > > 9. New commits that should be included in the 8.0 release should also be > > back-ported to branch_8x from master. > > >> > > >> This is not intended as a feature freeze, as I know there are still > some > > things being worked on for 8.0; however, it should let us clean up > master by > > removing as much deprecated code as possible, and give us an idea of any > > replacement work that needs to be done. > > >> > > >> > > >> On 19 Dec 2018, at 15:13, David Smiley <david.w.smi...@gmail.com> > > wrote: > > >> > > >> January. > > >> > > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.em...@gmail.com> > > 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 > > <david.w.smi...@gmail.com> 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%20LU > > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2 > > 0open%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 <jpou...@gmail.com> > > wrote: > > >> > > >> +1 > > >> > > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward > > <romseyg...@gmail.com> 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 <casstarg...@gmail.com> > > 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 > > <erickerick...@gmail.com> 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 < > jim.feren...@gmail.com> > > 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 > > <david.w.smi...@gmail.com> a écrit : > > >> >> >> > > >> >> >> +1 to a 7.6 —lots of stuff in there > > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize > > <nkn...@gmail.com> 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 > > <caomanhdat...@gmail.com> 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 > > <jim.feren...@gmail.com> 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 > > <casstarg...@gmail.com> 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 > > <jim.feren...@gmail.com> 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 > > <casstarg...@gmail.com> 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 > > <erickerick...@gmail.com> 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 > > <david.w.smi...@gmail.com> 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 > > <jim.feren...@gmail.com> 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%3DBlocke > > r%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 > > <jpou...@gmail.com> 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 > > <jpou...@gmail.com> 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%3DBlocke > > r%20and%20resolution%20%3D%20Unresolved%20 > > >> >> >>>>>>>>> >>>> > > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi > > <jim.feren...@gmail.com> 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 > > <erickerick...@gmail.com> 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 > > <caomanhdat...@gmail.com> 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 > > <jim.feren...@gmail.com> 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 > > <david.w.smi...@gmail.com> 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 > > <jpou...@gmail.com> 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 > > <rcm...@gmail.com> 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 <jpou...@gmail.com> 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 > > <jpou...@gmail.com> 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 > > <rcm...@gmail.com> 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 <jpou...@gmail.com> 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: dev- > > unsubscr...@lucene.apache.org > > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev- > > h...@lucene.apache.org > > >> >> >>>>>>>>> >>>>>> >>>>> >>> > > >> >> >>>>>>>>> >>>>>> >>>>> > > > >> >> >>>>>>>>> >>>>>> >>>>> > > >> >> >>>>>>>>> >>>>>> >>>>> > ----------------------------------------------------------- > > ---------- > > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev- > > unsubscr...@lucene.apache.org > > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev- > > h...@lucene.apache.org > > >> >> >>>>>>>>> >>>>>> >>>>> > > >> >> >>>>>>>>> >>>>>> >>> -- > > >> >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, > > Developer, Author, Speaker > > >> >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley > > | Book: http://www.solrenterprisesearchserver.com > > >> >> >>>>>>>>> >>>>>> > > >> >> >>>>>>>>> >>>>>> > -------------------------------------------------------------------- > > - > > >> >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev- > > unsubscr...@lucene.apache.org > > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev- > > h...@lucene.apache.org > > >> >> >>>>>>>>> >>>>>> > > >> >> >>>>>>>>> > -- > > >> >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, > > Author, Speaker > > >> >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > > http://www.solrenterprisesearchserver.com > > >> >> >>>>>>>>> > > >> >> >>>>>>>>> > --------------------------------------------------------------------- > > >> >> >>>>>>>>> To unsubscribe, e-mail: dev- > > unsubscr...@lucene.apache.org > > >> >> >>>>>>>>> For additional commands, e-mail: dev- > > h...@lucene.apache.org > > >> >> >>>>>>>>> > > >> >> >>> -- > > >> >> >>> > > >> >> >>> Nicholas Knize, Ph.D., GISP > > >> >> >>> Geospatial Software Guy | Elasticsearch > > >> >> >>> Apache Lucene Committer > > >> >> >>> nkn...@apache.org > > >> >> >> > > >> >> >> -- > > >> >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, > > Speaker > > >> >> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > > http://www.solrenterprisesearchserver.com > > >> >> > > >> >> > --------------------------------------------------------------------- > > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org > > >> >> > > >> > > > >> > > >> > > >> -- > > >> Adrien > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > >> For additional commands, e-mail: dev-h...@lucene.apache.org > > >> > > >> -- > > >> 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 > > >> > > >> > > >> > > > > > > -- > > Adrien > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- http://www.the111shift.com
