Hi,

this was done as a first step to preserve the "original Lucene/Solr approach": 
Make builds fail as soon as possible.

The idea was to move away from that definitely in release branches, but keep 
that snapshot approach in main. We may also think to stick with some fixed 
artifacts or do some "beta Lucene releases" -- or instruct snapshot servers to 
keep some versions for longer time and hardcode the version number. But this is 
all very complicated and not worth the trouble.

I think at the current state (without a Lucene 9.0 alpha/beta/final release) we 
should stick with "fail fast" aproch. Jenkins failures are a good way to 
trigger those failures. Once all stabilizes and Lucene 9.0.0 was released, Solr 
can depend on Lucene 9.0.0 and upgrade as needed.

Uwe

-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: [email protected]

> -----Original Message-----
> From: Jason Gerlowski <[email protected]>
> Sent: Thursday, April 15, 2021 1:59 PM
> To: [email protected]
> Subject: Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)
> 
> FYI, Mike Drob filed a separate issue for this yesterday (SOLR-15339).
> His ticket doesn't have a PR though so maybe that one should be closed
> as a duplicate?
> 
> I'm sure this has been discussed previously and I just missed it - but
> is there a way for us to lock the Solr build on a particular Lucene
> 9.0.0-SNAPSHOT build instead of continually pulling in the latest?
> That'd allow us to handle these API breaks in batches at our
> convenience, instead of having it happen as a "surprise" that we can't
> really control.  Or did we decide against that approach for some
> reason?
> 
> Best,
> 
> Jason
> 
> On Thu, Apr 15, 2021 at 7:23 AM Jan Høydahl <janhoy-
> [email protected]> wrote:
> >
> > Due to https://issues.apache.org/jira/browse/LUCENE-9387 being committed,
> removing some methods in Lucene.
> >
> > Issue https://issues.apache.org/jira/browse/SOLR-15341 to track this.
> >
> > Jan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to