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] >> >>
