Solr 4 had both an Alpha and Beta release. Came with essentially full release
cost, just indicated broad confidence in the initial releases and that users
should give it a spin if possible to allow a more reasonable .0 release.
[Mark Miller - Chat @
Spike](https://spikenow.com/r/a/?ref=spike-or
Hi Jan,
Thanks for doing most of the heavy lifting. I can help out with this.
-Anshum
On Thu, Jan 6, 2022 at 5:08 PM Jan Høydahl wrote:
> Hi,
>
> I created
> https://cwiki.apache.org/confluence/display/SOLR/DRAFT+Release+Notes+9.0
> to start drafting the release highlights.
>
> The list of cha
Hi,
I created
https://cwiki.apache.org/confluence/display/SOLR/DRAFT+Release+Notes+9.0 to
start drafting the release highlights.
The list of changes from "Major changes in 9" from RefGuide is long, and the
list from CHANGES is even longer. We need to:
1. Focus on the biggest, most important c
> There's a "hole" in the git-history in new solr repo, so filling that hole
> with the missing commits is a valid wish - so you can brose the entire
> history of Solr from one repo, and investigate recent changes to a file
> from IDE. I guess now GIT would lie to you and tell you that the previous
And to those of you who may not know, our Docker Solr image for Solr 8 uses
Java 11 even though Solr 8 supports Java 8. Solr 9 increases to require
Java 11 (not Java 17) and I'm proposing only bumping the Docker-Solr
default accordingly upwards (newer). In a container-ized world, I think
picking
I'm fine switching to java 17, but it would be nice to see some benchmarks
first before making it the default.
> Actually, it would be nice if we could publish all our images under apache
> name-space, and then have docker folks symlink /_/solr to these like they
> do for elastic.
>
We were expl
I don't think we are allowed by Apache policy to broadly announce non-official
releases like nightlies.
There should be more than enough in 9.0 to warrant a major release.
Most users will be reluctant to jump on a X.0.0 release, so we can mature a lot
in 9.0.x.
Perhaps if we start authoring the
Hi,
Definitely a possibility.
Or we could keep the official image on Java 11 to be conservative, and at the
same time publish some variants of our own under the apache namespace:
apache/solr:9.0.0-jre17
apache/solr:9.0.0-jdk17
apache/solr:9.0.0-jre11
apache/solr:9.0.0-jdk11
I don' tknow if we n
What do we think about a "beta" release, to give users (including
*ourselves* in many cases) more time to try out 9.0 to report issues? I
don't think a beta release would necessitate a typical feature freeze. If
we ultimately decline on a beta release, a counter-proposal would be to
promote our ni
I'd like to propose that our Docker image for Solr 9 move from Java 11 to
Java 17. Admittedly I don't have any familiarity with running 17, so I
would really like to hear from those of you using it. I'm guessing
(informed from some quick google searches) there are some ~minor
performance improvem
thanks Jan, PR looks good now! 😀
On Thu, Jan 6, 2022 at 11:52 AM Jan Høydahl wrote:
> False alarm, I had a dirty checkout.
> Please see if your PR passes precommit.
>
> Jan
>
> > 6. jan. 2022 kl. 19:49 skrev Jan Høydahl :
> >
> > Tim, I pushed a change to gradle that now uses hardcoded 9.0.0 fo
False alarm, I had a dirty checkout.
Please see if your PR passes precommit.
Jan
> 6. jan. 2022 kl. 19:49 skrev Jan Høydahl :
>
> Tim, I pushed a change to gradle that now uses hardcoded 9.0.0 for
> tests.luceneMatchVersion. That's a stop-gap, will make it dynamically follow
> the current luce
Tim, I pushed a change to gradle that now uses hardcoded 9.0.0 for
tests.luceneMatchVersion. That's a stop-gap, will make it dynamically follow
the current lucene-version, but somehow my gradle project picked up an old
version of org.apache.lucene.utils.Version class...
Now I get a new error
*
Thanks Uwe for adding the version in Jira. It was next on my RM list but I had
to commute home first :)
I have updated the blocker jira filter
https://issues.apache.org/jira/issues/?filter=12351219
Jan
> 6. jan. 2022 kl. 18:40 skrev Uwe Schindler :
>
> I changed that approximately at the time
I changed that approximately at the time when you were looking into this.
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Bence Szabó
> Sent: Thursday, January 6, 2022 6:12 PM
> To: dev@solr.apache.org
> Subje
Hello All!
I was trying to check the blocker list to see if there is anything I can
contribute with, but I observed that in the filter there is still the “fix
version = main (9.0)” which is not a valid fix version now. Can you please
check this?
Thanks!
Bence
> On 2022. Jan 6., at 17:53, Timot
Yep, the addVersion.py upgraded configs to 10.0.0 but we use Lucene 9.0.0 so we
need to set those back :)
Jan
> 6. jan. 2022 kl. 17:53 skrev Timothy Potter :
>
> Thanks for the update Jan!
>
> One of my PRs (sync'd with main) is now failing precommit with:
>
> 105 actionable tasks: 103 execut
Hi,
all those failures were caused by
https://issues.apache.org/jira/browse/SOLR-15876.
Actually errorprone can still not used on JDK 16 or later because it tries to
hack into the JDK. To enable it, there need to be changes inside the startup
options. So I reverted parts of that commit and ree
Thanks for the update Jan!
One of my PRs (sync'd with main) is now failing precommit with:
105 actionable tasks: 103 executed, 2 up-to-date
201FAILURE: Build failed with an exception.
202
203* Where:
204Script
'/home/runner/work/solr/solr/gradle/validation/solr.config-file-sanity.gradle'
line: 4
NOTICE:
Branch branch_9_x has been cut and versions updated to 10.0 on 'main' branch.
This follows the plan from previous notice about 9.0 release [1]. Here is what
will happen:
Today: Cut branch_9x and enter feature freeze on that branch
Next few weeks: Remove blockers, prepare build & release
There's a "hole" in the git-history in new solr repo, so filling that hole with
the missing commits is a valid wish - so you can brose the entire history of
Solr from one repo, and investigate recent changes to a file from IDE. I guess
now GIT would lie to you and tell you that the previous edit
Hi, Gus!
Thanks for the support. I feel lucky as my MR was noticed and already has
some discussion started. It seems it maybe become a part of the bigger
issue of unifying request status responses.
Hi, Mark!
Thank you for the answer and your advice. I tried this technique at first
and even get som
Removing the old tags is valid too. But the current state is
confusing/inconsistent and something should be done. Thanks for raising
this Houston.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Jan 6, 2022 at 8:56 AM Uwe Schindler wrote:
>
I agree with Dawid, why the hell do we need those tags? The old lucene-solr
repo can stay forever on Github. If I want to checkout an older version, I
would go into the old repo and check it out. In fact that’s also what tools may
do, because the old git repo is stated in the pom.xml files (or
Hi,
Actually sorting requires that you setup the whole query and all of its
iterators. Sure, you could then do stepping over documents not in the cache,
but the query has to be executed to actually do the sorting, you can just use
the bitset to maybe quicker step forward. You can do this inside
25 matches
Mail list logo
