In my personal opinion: We should wait until Lucene 9 is released and then switch to a fixed version. This was the plan from beginning and is also fine if it takes more months or half a year until Lucene releases 9.0.
The current behaviour is not bad: If Lucene changes, Jenkins detects a failure and we can open issue. This is not that different from before. The only problem I see is that suddenly a developer may be confronted with a compile failure caused by Gradle suddenly deciding that 24 hours are over and it needs to look for new snapshots. How about adding a system property that allows to use a specific snapshot version? Or maybe something to disable autoupdate on developer's machines? Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Dawid Weiss <[email protected]> > Sent: Thursday, April 15, 2021 2:50 PM > To: [email protected] > Subject: Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387) > > You could ask the infra team what the policy of snapshot retaining is. > I see some very old entries here: > http://repository.apache.org/content/groups/snapshots/org/apache/lucene/ > > but 9.0.0-SNAPSHOT only has a few. It's probably the count of releases > under a given version (not the age) that matters. > > D. > > On Thu, Apr 15, 2021 at 2:42 PM Jason Gerlowski <[email protected]> > wrote: > > > > > You can pin the dependency to a particular snapshot revision... the > > > problem > is those revisions don't stay in snapshot repositories forever > > > > Ah, I see. Presumably Solr could avoid this though by > > copying/republishing the particular snapshot we want our builds to use > > under the "org.apache.solr" groupId. e.g. Until 9.0 happens, Solr > > builds could rely on > > "org.apache.solr:lucene-core-frozen:9.0.0-SNAPSHOT" which Solr devs > > update at their leisure to point to different actual Lucene snapshots. > > > > If 9.0.0 is going to happen in the short term that's probably more > > trouble than it's worth. But if Solr's build breaks a few more times > > and 9.0.0 still seems distant it may seem worth the hassle at some > > point. But that's a bridge we can cross if we come to it I guess, and > > I'm thread hijacking at this point. Thanks guys. > > > > On Thu, Apr 15, 2021 at 8:28 AM Dawid Weiss <[email protected]> > wrote: > > > > > > > Wrt SNAPSHOT, I think we just need to be patient until Lucene releases > 9.0.0, then we can depend on that instead, and choose our own timing for > upgrading. > > > > > > You can pin the dependency to a particular snapshot revision... the > > > problem is those revisions don't stay in snapshot repositories forever > > > and once they're removed > > > you wouldn't be able to download/ resolve them. > > > > > > D. > > > > > > > > > > > Jan > > > > > > > > 15. apr. 2021 kl. 13:59 skrev Jason Gerlowski <[email protected]>: > > > > > > > > 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] > > > > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
