+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%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 <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%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 >> >> >>>>>>>>> >> <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%3DBlocker%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
