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
