It would be also useful to include aspects of supported/semi-supported JDKs and versions as well as potentially OS specific issues. Finally a small sentence of migration needs would be useful.
Some of this information is available on the web site, but I do think that it make sense to refer/link to them in the release notes. > Am 16.03.2019 um 04:35 schrieb David Smiley <david.w.smi...@gmail.com>: > > RE https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes > > I'm not sure if it'd make that much difference but I'd like to move the > release notes step down a little to follow the creation of the release branch > since that's when the features are truly frozen. Cool? > > Jan: Yeah totally agree RE quality varies. I think the release highlights is > a fundamental editorial task requiring someone looking at the entirety of the > issues, with plenty of judgement calls, to decide what's worth mentioning. > That "releasedocmaker" tool looks cool for generating a CHANGELOG.md, but I > don't think it'd be that great for the release highlights. Well it might be > okay but the results would simply be "a start" instead of starting with a > blank slate each release. Often times the biggest things that happen in a > release are comprised of multiple issues, not one; yet "releasedocmaker" is a > per-issue thing. > > Even though the release announcement has been published, it's never too late > to retroactively edit the information published to Solr's website! To that > end, I will edit the wiki version after sending this email to add an item > about enhanced nested document support. I think more should be said about > HTTP/2 by someone following it closely, and in particular mention that work > continues to 8.1 on it (and beyond?). Please mention what value this brings. > These two items are the big ones IMO but others may have more to add. > https://wiki.apache.org/solr/ReleaseNote80 > I will take care to re-publish it to the website next week. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > >> On Fri, Mar 15, 2019 at 4:20 AM Jan Høydahl <jan....@cominvent.com> wrote: >> The varying quality of release notes has been a problem for a long time. >> Sometimes random unimportant features are highlighted and the list gets way >> too long, >> and this time it was way too short. >> >> I think another alternative is to get some help from JIRA and Yetus here, by >> enabling the >> "release notes" field in JIRA and start using >> https://yetus.apache.org/documentation/0.9.0/releasedocmaker/ >> >> Have not tried it but I think it is in use by other projects. There would of >> course need to be >> some guidelines for when to use the field and not, but at least most of the >> work would >> be done by developers when resolving an important JIRA, not by RM at release >> time. >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >>> 14. mar. 2019 kl. 18:44 skrev Adrien Grand <jpou...@gmail.com>: >>> >>> +1 David The highlights section is embarrassing indeed, we should call >>> for action earlier in the future like the ReleaseTodo on the wiki >>> suggests[1]. >>> I don't think it is not the only problem though. In the couple >>> releases that I managed, I felt like the production of release notes >>> was one the most unpleasant parts of the process due to the fact that >>> not many people tend to help. It would be nice if we could figure out >>> a way to encourage collaboration of more committers on the production >>> of release notes. Or maybe we should stop doing this at release time, >>> and use the same approach as MIGRATE.txt and ask contributors to >>> document highlights at the same time as they push a change that is >>> worth highlighting? >>> >>> [1] https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes >>> >>> >>>> On Thu, Mar 14, 2019 at 2:34 PM David Smiley <david.w.smi...@gmail.com> >>>> wrote: >>>> >>>> The Solr highlights section of the announcement is severely incomplete as >>>> to appear embarrassing. >>>> In the absence of time/effort to fix it should have simply been omitted; >>>> the CHANGES.txt has details. >>>> That would not have been embarrassing. >>>> Maybe next time we could have a call to action about the release >>>> highlights that coincides with the creation of the release branch; >>>> that is a juncture in which the features are frozen and there's plenty of >>>> time to update. >>>> Last night I saw the call to action but it was woefully too late for me to >>>> help. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>>> >>>>> On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jpou...@gmail.com> wrote: >>>>> >>>>> I organized existing items of the Lucene release notes into sections >>>>> and added a new item about FeatureField, >>>>> LongPoint#newDistanceFeatureQuery and >>>>> LatLonPoint#newDistanceFeatureQuery. >>>>> >>>>>> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <romseyg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Jim and I have created wiki pages for the 8.0 release highlights here: >>>>>> https://wiki.apache.org/solr/ReleaseNote80 >>>>>> https://wiki.apache.org/lucene-java/ReleaseNote80 >>>>>> >>>>>> Feel free to edit and improve them - the Solr one in particular could do >>>>>> with some beefing up. >>>>>> >>>>>> >>>>>> On 20 Feb 2019, at 11:37, Noble Paul <noble.p...@gmail.com> wrote: >>>>>> >>>>>> I'm committing them, >>>>>> Thanks Ishan >>>>>> >>>>>> On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <romseyg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Awesome, thank you Ishan! >>>>>> >>>>>> On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya >>>>>> <ichattopadhy...@gmail.com> wrote: >>>>>> >>>>>> Would anyone like to volunteer to be release manager for 7.7.1? >>>>>> >>>>>> I can volunteer for 7.7.1. I'll start as soon as both these issues are >>>>>> committed. >>>>>> >>>>>> On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <romseyg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> We have two Solr issues that are serious enough to warrant a 7.7.1 >>>>>> release: SOLR-13248 and SOLR-13255. Given our backwards-compatibility >>>>>> guarantees, we should do this release before we restart the 8.0.0 >>>>>> process. >>>>>> >>>>>> Would anyone like to volunteer to be release manager for 7.7.1? Ideally >>>>>> we would get this done quickly so that I can continue releasing 8.0.0. >>>>>> >>>>>> On 14 Feb 2019, at 20:37, Mikhail Khludnev <m...@apache.org> wrote: >>>>>> >>>>>> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <m...@apache.org> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Thank you, Alan. Give me an hour. >>>>>> >>>>>> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseyg...@gmail.com: >>>>>> >>>>>> >>>>>> OK, let’s do an RC2. When do you think you can have a fix in? >>>>>> >>>>>> Mikhail, will you be able to get your fix in soon as well? >>>>>> >>>>>> >>>>>> >>>>>> Nope. Don't wait for SOLR-13126, it turns to be more complicated. >>>>>> >>>>>> >>>>>> >>>>>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <shalinman...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hi Alan, >>>>>> >>>>>> There is a work-around which is to change the default to using legacy >>>>>> assignment using cluster properties. But I don't like the idea of >>>>>> releasing something that we know is broken and asking everyone to set a >>>>>> cluster property to workaround it. I'd rather just rollback the commits >>>>>> that caused the problem and then release 8.0 >>>>>> >>>>>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <romseyg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Shalin, >>>>>> >>>>>> I'm not familiar with this bit of code - is there a workaround >>>>>> available? ie a way of using a different replica placement strategy >>>>>> when creating a collection? If there is, I'd be tempted to continue >>>>>> with the vote as is and then do an immediate 8.0.1 release once you have >>>>>> things fixed, particularly if we’re going to require a 7.7.1 as well. >>>>>> >>>>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <shalinman...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hi Alan, >>>>>> >>>>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a >>>>>> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In >>>>>> the interest of time, I propose rolling back SOLR-12739 which caused >>>>>> these issues. We can re-introduce it with proper fixes for the related >>>>>> issues in 8.1. >>>>>> >>>>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <romseyg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> The release candidate has already been built and voting is in progress, >>>>>> so it’s missed the boat unless there’s a respin. It does look like a >>>>>> nasty bug though, so if you have a fix then feel free too commit it to >>>>>> the 8_0 branch in case we do an 8.0.1 release. >>>>>> >>>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <m...@apache.org> wrote: >>>>>> >>>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ? >>>>>> >>>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <romseyg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch. >>>>>> >>>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <casstarg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even >>>>>> to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at >>>>>> all since there’s a lot of editing yet to be done for it. >>>>>> >>>>>> Cassandra >>>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <david.w.smi...@gmail.com>, >>>>>> wrote: >>>>>> >>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 >>>>>> which only touches the Solr Ref Guide. Could the Ref Guide for 8.0 >>>>>> include this even if it's committed after the 8.0 for the code? I could >>>>>> avoid touching CHANGES.txt if that helps (it'd be of dubious value to >>>>>> users browsing the change list any way). >>>>>> >>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseyg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Thanks for letting me know Jason. Your commit will have missed the cut, >>>>>> yes, but I don’t think it matters that much. It will get picked up in a >>>>>> respin or in any subsequent bug-fix release, and if RC1 passes the vote >>>>>> then we can just alter CHANGES.txt >>>>>> >>>>>> >>>>>> On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowsk...@gmail.com> wrote: >>>>>> >>>>>> Hey Alan, >>>>>> >>>>>> I just committed a minor inconsequential bugfix >>>>>> (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0. I didn't >>>>>> realize I was cutting it so close to your work on cutting RC1, but >>>>>> from commits I see you made this morning preparing for the RC I >>>>>> suspect I cut things _very_ close and just missed it. >>>>>> >>>>>> Hopefully my ill-timed commit to branch_8_0 doesn't create any >>>>>> problems for you on the release end. I'm happy to do whatever's >>>>>> easiest for you regarding that commit. It'd be nice to have it >>>>>> included in 8.0, but it's not imperative by any means if I've already >>>>>> missed the first RC, or it's easier for you to omit from potential >>>>>> subsequent RCs. Let me know if there's anything you'd like me to do >>>>>> (revert it, etc.). At a minimum if it doesn't make 8.0 I'll need to >>>>>> go back and update CHANGES.txt I think. >>>>>> >>>>>> Sorry again for the potential complication. I hate to be "that guy". >>>>>> Thanks for stepping up and handling the release. >>>>>> >>>>>> Best, >>>>>> >>>>>> Jason >>>>>> >>>>>> On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.feren...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Thanks for fixing Cassandra and sorry for the noise. I did this too many >>>>>> times in the past so I just mechanically changed the redirect without >>>>>> thinking of when or if the ref guide was also released. >>>>>> I'll be more careful next time ;). >>>>>> >>>>>> On another note, now that 7.7 is out and that we're preparing the >>>>>> release for 8.0 what do you think of removing/nuking the 7x branch. This >>>>>> was already discussed some time ago >>>>>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we >>>>>> reached a consensus and we have maybe new options with the move to >>>>>> gitbox. One option discussed in the thread was to remove all files and >>>>>> add a README that says that this branch is dead. I don't know if it's >>>>>> possible but we could also make the branch protected in gitbox in order >>>>>> to avoid new commits. What do you think ? Should we keep this branch and >>>>>> just consider new commits as useless or should we try to "clean up" all >>>>>> Nx branches that are not active anymore (5x, 6x, 7x) ? >>>>>> >>>>>> Jim >>>>>> >>>>>> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstarg...@gmail.com> >>>>>> a écrit : >>>>>> >>>>>> >>>>>> I’d like to remind RMs that when finishing up a release, we can’t just >>>>>> do a blanket find/replace in .htaccess to update the version. If we’re >>>>>> not going to coordinate binary releases with Ref Guide releases, we need >>>>>> to be careful not to change the redirects unless that version’s Ref >>>>>> Guide release is also imminent. >>>>>> >>>>>> This is noted in the ReleaseToDo >>>>>> (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), >>>>>> but I’ve seen it occur a little too soon for the past few releases…in >>>>>> those cases, the Ref Guide release was pretty close so it didn’t matter >>>>>> that much. >>>>>> >>>>>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it >>>>>> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone >>>>>> else needs to maybe take care of it), but all non-version specific Ref >>>>>> Guide link is now being routed to a non-existent 7.7 path. It’s easy to >>>>>> fix, but we have an easy way to avoid routing people to dead links. >>>>>> >>>>>> Cassandra >>>>>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseyg...@gmail.com>, >>>>>> wrote: >>>>>> >>>>>> Once 7.7 is out the door, we should get on with releasing 8.0. I >>>>>> volunteer to be the manager for this round. My current plan is to build >>>>>> a release candidate early next week, as soon as the 7.7 release has been >>>>>> announced. >>>>>> >>>>>> On 8 Feb 2019, at 09:07, Alan Woodward <romseyg...@gmail.com> wrote: >>>>>> >>>>>> It is a shame, I agree, but some of this stuff has been deprecated since >>>>>> 3.6, so another release cycle won’t hurt :). We should prioritise >>>>>> cleaning this stuff up once 8.0 is out of the door though. >>>>>> >>>>>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smi...@gmail.com> wrote: >>>>>> >>>>>> Okay. I suppose the issue is that it's simply too late in the 8.0 cycle >>>>>> to remove things that have been deprecated in previous releases? >>>>>> solr.LatLonType is one example. It's a shame to keep around such things >>>>>> further. >>>>>> >>>>>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseyg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Not quite - the plan is to remove things entirely in 9.0, but we may >>>>>> need to back port some extra deprecations to 8x. We don’t necessarily >>>>>> need them in 8.0 though - we can deprecate in 8.1 and remove in 9 >>>>>> without any problems. I opened the issues to ensure that we didn’t keep >>>>>> carrying deprecated code through any further releases. >>>>>> >>>>>> >>>>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smi...@gmail.com> wrote: >>>>>> >>>>>> I want to ensure people are aware of two issues "Remove deprecated code >>>>>> in master" that Alan filed: >>>>>> >>>>>> https://issues.apache.org/jira/browse/SOLR-13138 >>>>>> https://issues.apache.org/jira/browse/LUCENE-8638 >>>>>> There's a "master-deprecations" branch as well. >>>>>> >>>>>> Although both issues are marked "master (9.0)", I think the intent is >>>>>> actually 8.0 so that we are finally rid of the deprecated code? >>>>>> >>>>>> ~ David >>>>>> >>>>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kris...@apache.org> wrote: >>>>>> >>>>>> >>>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0. >>>>>> I'm keeping any eye on the builds this weekend but all indications are >>>>>> no issues so far. >>>>>> >>>>>> Kevin Risden >>>>>> >>>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpou...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look? >>>>>> >>>>>> See eg. >>>>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console. >>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nkn...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Thank you Jim. LUCENE-8669 has been merged. >>>>>> >>>>>> - Nick >>>>>> >>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.feren...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the >>>>>> first RC when your patch is merged. >>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea >>>>>> to rush this in for 8.0. Would it be safer to target another version in >>>>>> order to take some time to ensure that it's not breaking anything ? I >>>>>> guess that your concern is that a change like this should happen in a >>>>>> major version but I wonder if it's worth the risk. I don't know this >>>>>> part of the code and the implications of such a change so I let you >>>>>> decide what we should do here but let's not delay the release if we >>>>>> realize that this change requires more than a few days to be merged. >>>>>> >>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nkn...@gmail.com> a écrit >>>>>> : >>>>>> >>>>>> >>>>>> Hey Jim, >>>>>> >>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along >>>>>> with a pretty straightforward patch. This is a critical one that I think >>>>>> needs to be in for 7.7 and 8.0. Can I set this as a blocker? >>>>>> >>>>>> On Wed, Jan 30, 2019 at 1:07 PM >>>>>> >>>>>> Kevin Risden <kris...@apache.org> wrote: >>>>>> >>>>>> >>>>>> Jim, >>>>>> >>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get >>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is >>>>>> currently under review. >>>>>> >>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others >>>>>> feel this should make it into 8.0 or not. >>>>>> >>>>>> Kevin Risden >>>>>> >>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.feren...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we >>>>>> don't handle two concurrent releases in our tests >>>>>> (https://issues.apache.org/jira/browse/LUCENE-8665). >>>>>> Since we want to release 7.7 first I created the Jenkins job for this >>>>>> version only and will build the first candidate for this version later >>>>>> this week if there are no objection. >>>>>> I'll restore the version bump for 8.0 when 7.7 is out. >>>>>> >>>>>> >>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.feren...@gmail.com> a >>>>>> écrit : >>>>>> >>>>>> >>>>>> Hi, >>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now >>>>>> create the Jenkins tasks for these versions, Uwe can you also add them >>>>>> to the Policeman's Jenkins job ? >>>>>> This also means that the feature freeze phase has started for both >>>>>> versions (7.7 and 8.0): >>>>>> >>>>>> No new features may be committed to the branch. >>>>>> Documentation patches, build patches and serious bug fixes may be >>>>>> committed to the branch. However, you should submit all patches you want >>>>>> to commit to Jira first to give others the chance to review and possibly >>>>>> vote against the patch. Keep in mind that it is our main intention to >>>>>> keep the branch as stable as possible. >>>>>> All patches that are intended for the branch should first be committed >>>>>> to the unstable branch, merged into the stable branch, and then into the >>>>>> current release branch. >>>>>> Normal unstable and stable branch development may continue as usual. >>>>>> However, if you plan to commit a big change to the unstable branch while >>>>>> the branch feature freeze is in effect, think twice: can't the addition >>>>>> wait a couple more days? Merges of bug fixes into the branch may become >>>>>> more difficult. >>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will >>>>>> delay a release candidate build. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Jim >>>>>> >>>>>> >>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili >>>>>> <tommaso.teof...@gmail.com> a écrit : >>>>>> >>>>>> >>>>>> sure, thanks Jim! >>>>>> >>>>>> Tommaso >>>>>> >>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi >>>>>> <jim.feren...@gmail.com> ha scritto: >>>>>> >>>>>> >>>>>> Go ahead Tommaso the branch is not created yet. >>>>>> The plan is to create the branches (7.7 and 8.0) tomorrow or wednesday >>>>>> and to announce the feature freeze the same day. >>>>>> For blocker issues that are still open this leaves another week to work >>>>>> on a patch and we can update the status at the end of the week in order >>>>>> to decide if we can start the first build candidate >>>>>> early next week. Would that work for you ? >>>>>> >>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili >>>>>> <tommaso.teof...@gmail.com> a écrit : >>>>>> >>>>>> >>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 >>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time. >>>>>> >>>>>> Regards, >>>>>> Tommaso >>>>>> >>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand >>>>>> <jpou...@gmail.com> ha scritto: >>>>>> >>>>>> >>>>>> Hi Noble, >>>>>> >>>>>> No it hasn't created yet. >>>>>> >>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.p...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Is the branch already cut for 8.0? which is it? >>>>>> >>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smi...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> I finally have a patch up for >>>>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 >>>>>> blocker) that I feel pretty good about. This provides a key part of the >>>>>> nested document support. >>>>>> I will work on some documentation for it this week -- SOLR-13129 >>>>>> >>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan....@cominvent.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> I don't think it is critical for this to be a blocker for 8.0. If it >>>>>> gets fixed in 8.0.1 that's ok too, given this is an ooold bug. >>>>>> I think we should simply remove the buffering feature in the UI and >>>>>> replace it with an error message popup or something. >>>>>> I'll try to take a look next week. >>>>>> >>>>>> -- >>>>>> Jan Høydahl, search solution architect >>>>>> Cominvent AS - www.cominvent.com >>>>>> >>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe >>>>>> <tomasflo...@gmail.com>: >>>>>> >>>>>> I think the UI is an important Solr feature. As long as there is a >>>>>> reasonable time horizon for the issue being resolved I'm +1 on making it >>>>>> a blocker. I'm not familiar enough with the UI code to help either >>>>>> unfortunately. >>>>>> >>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.h...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> It looks like someone tried to make it a blocker once before... And it's >>>>>> actually a duplicate of an earlier issue >>>>>> (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a >>>>>> question of whether or not overall quality has a bearing on the decision >>>>>> to release. As it turns out the screen shot I posted to the issue is >>>>>> less than half of the shards that eventually got created since there was >>>>>> an outstanding queue of requests still processing at the time. I'm now >>>>>> having to delete 50 or so cores, which luckily are small 100 Mb initial >>>>>> testing cores, not the 20GB cores we'll be testing on in the near >>>>>> future. It more or less makes it impossible to recommend the use of the >>>>>> admin UI for anything other than read only observation of the cluster. >>>>>> Now imagine someone leaves a browser window open and forgets about it >>>>>> rather than browsing away or closing the window, not knowing that it's >>>>>> silently pumping out requests after showing an error... would completely >>>>>> hose a node, and until they tracked down the source of the requests, >>>>>> (hope he didn't go home) it would be impossible to resolve... >>>>>> >>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpou...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Releasing a new major is very challenging on its own, I'd rather not >>>>>> call it a blocker and delay the release for it since this isn't a new >>>>>> regression in 8.0: it looks like a problem that has affected Solr >>>>>> since at least 6.3? I'm not familiar with the UI code at all, but >>>>>> maybe this is something that could get fixed before we build a RC? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.h...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> 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 >>>>>> -- >>>>>> >>>>>> &g >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sincerely yours >>>>>> Mikhail Khludnev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ----------------------------------------------------- >>>>>> Noble Paul >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >>>>> >>> >>> >>> -- >>> Adrien >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>
