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