+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
