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]
