I have a number of changes in a local branch for the 8.0 Ref Guide page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t intended to push my branch, but I could if it helps. I also have a bunch of unfinished content I started about nested documents, but tearing apart the CHANGES.txt to figure out what is new and how that impacts upgrades is incredibly painful and time-consuming, and I don’t have a ton of time these days. This is why the 8.0 Ref Guide isn’t out yet.
Tangentially, I feel like we need to work something else out about Wiki release notes (and, remember, wiki.apache.org is going away really soon now) and the Ref Guide. It’s odd to me that one person decides how to present what’s new in the Wiki release notes, and someone else decides how to present a whole other set of content about the same set of features for the Ref Guide. Usually I skip the what’s new part for the minor releases, but for major ones, there needs to be a comprehensive “here’s what’s new and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the major version process now. Anyway, let me know if you want to see what I have so far, and I’ll try to find some time to push it or make a patch. On Apr 30, 2019, 8:00 AM -0500, David Smiley <david.w.smi...@gmail.com>, wrote: > Hi Dat, > > I plan to update Solr's release notes for 8.0 retroactively. > https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs; I > wrote this well over a month ago. Can you please enhance the part on HTTP2 > to be more informative? For example... what *benefit* does HTTP2 bring to > internode communication? I know you benchmarked things. Maybe mention the > road to full HTTP2 continues into 8.x? > > I'm sending this to the dev list so really anyone else can help like list > other major features... though I think maybe it's just these two. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > ---------- Forwarded message --------- > > From: David Smiley <david.w.smi...@gmail.com> > > Date: Thu, Mar 14, 2019 at 9:34 AM > > Subject: Re: Lucene/Solr 8.0 > > To: Solr/Lucene Dev <dev@lucene.apache.org> > > > > > > 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 > > > >
