I agree on being conservative here. But if it turns out to work well, we could
consider publishing an additional solr:9.4.0-jre21 tag. That way early adopters
have a choice. If I remember correctly, Java 21 has some improvements that can
benefit some vector workloads or something, so I see a
I agree that having to write "MatcherAssert.assertThat" each time is
tedious and makes my code ugly. So finally I try to avoid this nice
construction. Not satisfying.
Le mer. 25 oct. 2023 à 22:44, Kevin Risden a écrit :
> It came in as part of
>
It came in as part of
https://github.com/apache/solr/pull/947#issuecomment-1279651282
I linked to one of the comments there since this was discussed on the PR.
Basically it removes a ton of deprecated usages. If/when we upgrade Junit
we should hopefully have much less to do.
So to answer your
Begin Rant...
$ tail -6 ./gradle/validation/forbidden-apis/junit.junit.all.txt
junit.framework.TestCase @ All classes should derive from LuceneTestCase
junit.framework.Assert @ Use org.junit.Assert
junit.framework.** @ Use org.junit
org.junit.Assert#assertThat(**) @ Use
Hi All,
I have a PR[1] to remove the "highest" field from VersionBucket (highest
doc version of the bucket).
By reading the code, I understand that this field is used for an
optimization in the case of a distributed update and non-leader checking a
doc version for an update. But I wondered about
