Also sorry for maybe another blocker but LUCENE-9450 <https://issues.apache.org/jira/browse/LUCENE-9450> might be. As things stand now we will force a complete reindex on upgrade to Lucene 9.0 for any user using taxonomy facets ...
Mike McCandless http://blog.mikemccandless.com On Sat, Jul 3, 2021 at 2:00 AM Tomoko Uchida <tomoko.uchida.1...@gmail.com> wrote: > There is a recent conversation about LUCENE-9855 should be a blocker for > 9.0. > Sorry for adding another blocker - I'll be working on it. > > Tomoko > > 2021年6月30日(水) 22:59 Mayya Sharipova <mayya.sharip...@elastic.co.invalid>: > > > > I will be working on LUCENE-9334, I will try to finish it soon. > > > > On Wed, Jun 30, 2021 at 12:40 AM David Smiley <dsmi...@apache.org> > wrote: > >> > >> There are also deprecations to remove: > https://issues.apache.org/jira/browse/LUCENE-8638 > >> > >> ~ David Smiley > >> Apache Lucene/Solr Search Developer > >> http://www.linkedin.com/in/davidwsmiley > >> > >> > >> On Tue, Jun 29, 2021 at 2:43 PM Mike Drob <md...@apache.org> wrote: > >>> > >>> Looks like just LUCENE-9334 remains? > >>> > >>> On Wed, Apr 14, 2021 at 10:18 PM Julie Tibshirani <juliet...@gmail.com> > wrote: > >>> > > >>> > Hello everyone! I will pick up LUCENE-9908. > >>> > > >>> > > >>> > I had marked LUCENE-9583 as a blocker but I'm on board with removing > its blocker status given we can make changes later. I hope to come back to > the issue soon with some ideas. > >>> > > >>> > > >>> > Julie > >>> > > >>> > > >>> > On Wed, Apr 14, 2021 at 12:42 PM Adrien Grand <jpou...@gmail.com> > wrote: > >>> >> > >>> >> I agree that we can remove the blocker status from LUCENE-9583 and > take advantage of the fact that these new APIs are experimental to improve > things later. > >>> >> > >>> >> For the renaming issue, maybe we could just make vectors plural for > now for consistency and revisit other options later. > >>> >> > >>> >> On Wed, Apr 14, 2021 at 8:21 PM Michael Sokolov <msoko...@gmail.com> > wrote: > >>> >>> > >>> >>> Thanks Adrien; I plan to tackle LUCENE-9905. > >>> >>> > >>> >>> I don't have ideas about how to move forward on LUCENE-9583; I > spent > >>> >>> significant amount of time trying various permutations on that API, > >>> >>> and what we have was the best compromise I could find at the time, > so > >>> >>> I'm not sure I agree it's a Blocker, yet I'm open to improvements. > >>> >>> Maybe Julie will propose something? > >>> >>> > >>> >>> There is also a vector-related renaming issue Tomoko had opened, > which > >>> >>> I thought was marked Blocker, but I guess no longer is. Previously > I > >>> >>> had hoped to get some strong consensus, but that proved > challenging. > >>> >>> Given that, I'm OK leaving things as-is, marking these apis > >>> >>> @experimental and potentially revisiting naming issues later, eg > once > >>> >>> we have a second vector ANN implementation. > >>> >>> > >>> >>> On Wed, Apr 14, 2021 at 11:07 AM Adrien Grand <jpou...@gmail.com> > wrote: > >>> >>> > > >>> >>> > Hi Mike, > >>> >>> > > >>> >>> > Here's what I know about the remaining blockers: > >>> >>> > > >>> >>> > LUCENE-9908 - Move VectorValues#search to VectorReader and > LeafReader > >>> >>> > This was discussed on the mailing list and it looks like there > was agreement on making that change. If someone has cycles and can take it, > please go ahead, otherwise I'll try to allocate some time to it. I'm > expecting this change to be rather straightforward. > >>> >>> > > >>> >>> > LUCENE-9905 - Revise approach to specifying NN algorithm > >>> >>> > This is a change to how we've been thinking about configuring > the ANN algorithm. I don't know if someone plans to work on it. > >>> >>> > > >>> >>> > LUCENE-9583 - How should we expose VectorValues.RandomAccess > >>> >>> > We'd like to get rid of this sub interface, but I'm not the best > person to comment on how much work this needs. Maybe Mike S or Julie can > give more info. > >>> >>> > > >>> >>> > LUCENE-9334 - Require consistency between data-structures on a > per-field basis > >>> >>> > Mayya has been working on this one and it's very close. > >>> >>> > > >>> >>> > LUCENE-9047 - Directory APIs should be little endian > >>> >>> > Ignacio and Julie have been working on this one and it is close > as well. > >>> >>> > > >>> >>> > > >>> >>> > On Tue, Apr 13, 2021 at 10:59 PM Mike Drob <md...@mdrob.com> > wrote: > >>> >>> >> > >>> >>> >> Michael, did you get a chance to mark the issues you were > thinking of as blockers? > >>> >>> >> > >>> >>> >> Adrien, I see that the remaining open blockers look mostly like > your open issues. Two of them have recent activity, but LUCENE-9047 would > need to be brought back to the lucene repo. Is this an accurate view of the > state of things? > >>> >>> >> > >>> >>> >> Now that I'm done with 8.8.2, I would love to see how we can > continue to make headway on 9.0! > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> On Mon, Mar 29, 2021 at 3:25 PM Michael Sokolov < > msoko...@gmail.com> wrote: > >>> >>> >>> > >>> >>> >>> There has been some discussion around a few code visibility > and naming > >>> >>> >>> issues related to "VectorFormat" as it is called today. I'd > like to > >>> >>> >>> get that sorted out before 9.0 - I'll hunt up the ticket(s) > and mark > >>> >>> >>> as blockers > >>> >>> >>> > >>> >>> >>> On Sun, Mar 28, 2021 at 11:02 AM Adrien Grand < > jpou...@gmail.com> wrote: > >>> >>> >>> > > >>> >>> >>> > Hello Jan, > >>> >>> >>> > > >>> >>> >>> > The list of blockers should be mostly up-to-date: > https://issues.apache.org/jira/browse/LUCENE-9661?jql=project%3D%22Lucene%20-%20Core%22%20and%20priority%3DBlocker%20and%20fixVersion%3D%22main%20(9.0)%22 > . > >>> >>> >>> > > >>> >>> >>> > On Sat, Mar 27, 2021 at 7:21 PM Jan Høydahl < > jan....@cominvent.com> wrote: > >>> >>> >>> >> > >>> >>> >>> >> Hi, > >>> >>> >>> >> > >>> >>> >>> >> Where are we at with the Lucene 9.0 release planning? > >>> >>> >>> >> > >>> >>> >>> >> The git split is largely done. Not sure about the build. > >>> >>> >>> >> Let's update the umbrella issue > https://issues.apache.org/jira/browse/LUCENE-9375 for known remaining > cleanup tasks. > >>> >>> >>> >> The one on that list is releaseWizard, but as Adrien says > there are also other scripts that need updating. > >>> >>> >>> >> > >>> >>> >>> >> Jan > >>> >>> >>> >> > >>> >>> >>> >> 13. jan. 2021 kl. 15:10 skrev Adrien Grand < > jpou...@gmail.com>: > >>> >>> >>> >> > >>> >>> >>> >> +1 to start planning 9.0. > >>> >>> >>> >> > >>> >>> >>> >> Since you mentioned the Gradle build, I believe that we > still need to migrate some of the release tooling from Ant to Gradle, e.g. > dev-tools/scripts/addBackcompatIndexes.py. These scripts are not easy to > test without actually doing a release so the 9.0 RM might have some > debugging to do. > >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> >> On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov < > msoko...@gmail.com> wrote: > >>> >>> >>> >>> > >>> >>> >>> >>> Hi everyone, as we head into a new year full of optimism, > is it time > >>> >>> >>> >>> to start discussing the next major release? We released > 8.0 on Jun 18, > >>> >>> >>> >>> 2019, over 18 months ago. Since then we've switched to a > gradle-based > >>> >>> >>> >>> build. We have added vector-valued fields and an HNSW > neighbor search > >>> >>> >>> >>> algorithm for them. At the same time Solr has been > getting a major > >>> >>> >>> >>> overhaul which should justify a release, I think? IIRC > there was talk > >>> >>> >>> >>> of making 9.0 be the first release of Solr as its own TLP. > Is it time > >>> >>> >>> >>> to start planning for that now? > >>> >>> >>> >>> > >>> >>> >>> >>> -Mike > >>> >>> >>> >>> > >>> >>> >>> >>> > --------------------------------------------------------------------- > >>> >>> >>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> >>> >>> >>> For additional commands, e-mail: > dev-h...@lucene.apache.org > >>> >>> >>> >>> > >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> >> -- > >>> >>> >>> >> Adrien > >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > -- > >>> >>> >>> > 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 > >>> >>> > >>> >> > >>> >> > >>> >> -- > >>> >> 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 > >
