I'd ask Infra what the best way to do this. We don't want to publish to maven central and snapshots are too "unpersistent".
Elasticsearch is doing this (release Lucene and push to their own REPO). We should maybe just add some smoketester check that prevents a real release with such a dependency. Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Jan Høydahl <[email protected]> > Sent: Friday, April 30, 2021 4:46 PM > To: [email protected] > Subject: Re: Proposal to pin the Lucene snapshot version on main > > Solr can build a 9.0.0-solr-20210430 version and push it to internal ASF repo, > can't we? > > Jan > > > 30. apr. 2021 kl. 16:41 skrev Mike Drob <[email protected]>: > > > > Note that this happened again last night, and Jason was able to > > quickly fix it. But it makes things like 'git bisect' impossible to > > chase a bug because none of the older versions will compile. > > > > I don't think we can pin to a SNAPSHOT version because there are no > > guarantees about how long those versions stick around. Maybe we can > > ask Lucene to release a 9.0.0-alpha just so that we have some kind of > > tag that we can stick to, with the understanding that this alpha tag > > has no guarantees about future compatibility. > > > > On Fri, Apr 30, 2021 at 2:36 AM Dawid Weiss <[email protected]> > wrote: > >> > >> But how do you pin to an intermediate version without a snapshot maven > >> repository that would keep those pinned artifacts? > >> > >> Dawid > >> > >> On Thu, Apr 29, 2021 at 9:45 PM David Smiley <[email protected]> > wrote: > >>> > >>> +1 Jan, that sounds complementary to what I propose. We'd get > notifications via Jenkins that there are some compatibility issues. But we'd > still > pin a version and upgrade at a time of our choosing. > >>> > >>> ~ David Smiley > >>> Apache Lucene/Solr Search Developer > >>> http://www.linkedin.com/in/davidwsmiley > >>> > >>> > >>> On Thu, Apr 29, 2021 at 11:35 AM Jan Høydahl <janhoy- > [email protected]> wrote: > >>>> > >>>> It could be feasible to let Jenkins do a periodic run (weekly?) of main > branch with lucene SNAPSHOT. We can perhaps define a gradle property to > override lucene version? -Dlucene.version=10.0.0-SNAPSHOT which Jenkins > could easily trigger. I think a similar thought has been discussed before. > >>>> > >>>> Jan > >>>> > >>>> 29. apr. 2021 kl. 17:20 skrev Gus Heck <[email protected]>: > >>>> > >>>> We should still have some way of detecting these breakages early rather > than later (or worse yet after lucene has released something). The easiest > time > to fix a problem is before someone else built on top of it. > >>>> > >>>> On Thu, Apr 29, 2021 at 11:15 AM Jason Gerlowski > <[email protected]> wrote: > >>>>> > >>>>> +1 > >>>>> > >>>>> On Thu, Apr 29, 2021 at 11:12 AM Jan Høydahl > >>>>> <[email protected]> wrote: > >>>>>> > >>>>>> +1 to pin. There will probably be a few more months until 9.0 given > that 8.9 must be released first etc. > >>>>>> > >>>>>> Jan > >>>>>> > >>>>>> 29. apr. 2021 kl. 17:08 skrev David Smiley <[email protected]>: > >>>>>> > >>>>>> There have been some discussions previously about whether to pin the > Lucene snapshot version until 9.0 is out, so that we update it manually > instead > of it being ~daily. Most recently in Slack but also this thread "Solr fails > with > current lucene-9.0.0-SNAPSHOT (LUCENE-9387)". I think the rate of > spontaneous breaking has increased beyond my comfort level from being > ambivalent on the matter to preferring more control of when we update. I > know that may be as late as possible :-) but it minimizes > surprises/disruptions. > If there are no vetos on the matter in this thread, I'll throw up a PR. > >>>>>> > >>>>>> ~ David Smiley > >>>>>> Apache Lucene/Solr Search Developer > >>>>>> http://www.linkedin.com/in/davidwsmiley > >>>>>> > >>>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>> > >>>> > >>>> -- > >>>> http://www.needhamsoftware.com (work) > >>>> http://www.the111shift.com (play) > >>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> 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]
