On Tue, May 5, 2020 at 11:41 AM Jan Høydahl <jan....@cominvent.com> wrote:
As it is today, deveopers have had to do necessary Solr changes at the same > time when doing changes in Lucene. This is not really fair to the (mainly) > Lucene developers. It is not fair to Solr either, as such work might be > done in a hasty fashion and/or in a sub optimal way due to lack of > familiarity with Solr code base; like we unfortunately have seen a couple > of times in the past (not trying to blame anyone). With Lucene as a > dependency, Solr can choose to stay on same Lucene version for a couple of > releases while taking the time to work out the proper way to adapt to > changed Lucene APIs or to sort out performance issues. > +1, that is a great point, Jan. This will mean that the (any) necessary Solr source code changes that go along with a Lucene change will (sometimes) be done with higher quality, more thought, better expertise, etc., which I agree will be good for ongoing Solr development, help prevent accidental performance regressions, etc. Net/net that's a big positive for Solr, in addition to having a stronger independent identity (https://solr.apache.org). > Question: When Lucene no longer has the Solr test suite to help catch > bugs, how long time would it take from a Lucene commit, before Solr/ES > Jenkins instances would have had time to produce a build and run tests? > Would it be possible to setup a trigger in Solr Jenkins? > That's a great question! Maybe Elasticsearch developers could chime in, since this already happened for them many times by now :) I would think there are technical solutions to let the Solr CI build pull the latest Lucene snapshot build, to keep the latency lowish, but I do not know the details. Mike
