Apologies for breaking branch 8.x with my cherry-pick, double checking
things locally and will push a fix shortly.
On Mon, Nov 30, 2020 at 2:53 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build: https://ci-builds.apache.org/job/Lucene/job/Solr-Artifacts-8.x/114/
>
> No tests ra
Check out this ticket:
https://issues.apache.org/jira/browse/SOLR-14673
There are lots of different ways that this could be applied as a
replacement for DIH.
Joel Bernstein
http://joelsolr.blogspot.com/
On Mon, Nov 30, 2020 at 9:56 AM Erick Erickson
wrote:
> For what I suggested, there’s no
For what I suggested, there’s no code to write, these streams exist already.
As far as supporting the more complex cases… I’m -1 for adding special code to
streaming. DIH has many moving parts. Each of those parts was put there for a
reason, and needed to be supported through successive Solr rel
I get your point on different audiences... sometimes I peer-review us on
dubiously written CHANGES.txt entries to be more user friendly. However,
this attention could and should be given to JIRA issue summaries as well.
We all benefit from that. Also, for Solr in particular, the need for
examinin
Hi,
You can have both in same JAR file. No need to split releases, this would
confuse users even more. For some stuff you just have to make sure that both
usage possibilities are available, but in general the Gradle build should
switch to "module" compilation mode, so all dependencies are check
I think it'd be fun to switch to the module system at some point.
Perhaps offer dual release, initially (modules + JARs).
Dawid
On Mon, Nov 30, 2020 at 10:37 AM Uwe Schindler wrote:
>
> Hi,
>
> I wanted to just add:
> We also need some testing of the artifacts! Our standard test environment
> c
Hi,
I wanted to just add:
We also need some testing of the artifacts! Our standard test environment can't
do testing of module system. This needs some "integration" tests: A project
using the JAR files on module path - no classpath. And here it must be JAR
files, the non-packaged class files w
I have a preference for maintaining a separate CHANGES file because it
allows us to keep JIRA focused for a committer/contributor audience while
the CHANGES file can describe changes that matter for users. Elasticsearch
uses a similar mechanism for release notes to what you are proposing, using
Git
