I think adding git submodule means that we have to add back in all the build code for it. At which point, I'd rather just copy and commit the code they have so we don't have to learn another git system. I've heard submodules don't play nice with Jenkins, but don't have any direct experience with them.
On Fri, Apr 30, 2021 at 2:08 PM David Smiley <[email protected]> wrote: > > Other than literally adding the git submodule, would we do anything else to > modify the gradle build so that or do we (and Jenkinsfile) have to manually > do a step to install Lucene before proceeding? Manually wouldn't necessarily > be bad, even if a first step, considering this is likely to only last until > 9.0. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Apr 30, 2021 at 3:03 PM Ishan Chattopadhyaya > <[email protected]> wrote: >> >> Can we give submodules a try for few weeks and then take an informed >> decision? >> >> On Sat, 1 May, 2021, 12:32 am Ishan Chattopadhyaya, >> <[email protected]> wrote: >>> >>> I fully support git submodules. +1 dawid. >>> Most of the problems with it that people complain about, are perceived >>> problems, not real ones. >>> >>> On Fri, 30 Apr, 2021, 10:50 pm Dawid Weiss, <[email protected]> wrote: >>>> >>>> We've had that discussion before -- this is where git submodules are >>>> excellent to work with - you know exactly which version you had for >>>> each commit... this said, there are other pitfalls to using submodules >>>> so it's not all rosy either. >>>> >>>> On Fri, Apr 30, 2021 at 4:41 PM Mike Drob <[email protected]> wrote: >>>> > >>>> > 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 >>>> > > > <[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]
