+1, agree with Uwe.
On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
wrote:
>
> +1 to Uwe's suggestion
>
> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, wrote:
>>
>> +1 to uwe's suggestion
>>
>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul wrote:
>>>
>>> I think this is a reasonable suggestion
+1 to Uwe's suggestion
On Mon, 22 Nov, 2021, 11:13 am Gus Heck, wrote:
> +1 to uwe's suggestion
>
> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul wrote:
>
>> I think this is a reasonable suggestion Uwe.
>>
>> - We don't need to bring Gradle to 8.x
>> - We can release 8.12 from a fork of 8.11.
>>
+1 to uwe's suggestion
On Sun, Nov 21, 2021 at 10:42 PM Noble Paul wrote:
> I think this is a reasonable suggestion Uwe.
>
> - We don't need to bring Gradle to 8.x
> - We can release 8.12 from a fork of 8.11.
> - we don't need to keep the Lucene source files in that branch. We can
> nuke it and
I think this is a reasonable suggestion Uwe.
- We don't need to bring Gradle to 8.x
- We can release 8.12 from a fork of 8.11.
- we don't need to keep the Lucene source files in that branch. We can nuke
it and just keep the Lucene binaries
On Mon, Nov 22, 2021, 8:49 AM Uwe Schindler wrote:
>
Hi,
If this is really needed, I'd propose the following:
- fork the branch_8_11 to solr's repo
- delete all subdirectories below lucene, keep common-build and other stuff.
- add a single ivy.xml there that refers to all lucene jars of 8.11.x (latest)
- adapt solr's "copy-lucene-jars" ant task to
All Solr users using 8x and they will need some time to get comfortable
with 9x . So, there is a good chance we may need to release an 8.12 based
on Lucene 8.11
On Mon, Nov 22, 2021, 8:22 AM Adrien Grand wrote:
> +1 to making branch_8x read-only as Uwe suggested
>
> I think Uwe's other point is
+1 to making branch_8x read-only as Uwe suggested
I think Uwe's other point is also important: if we ever wanted to do a Solr
8.12, it'd probably be a better option to fork the 8.11 branch than to try
to reuse branch_8x. So we don't need to tie the decision about what we want
to do with branch_8x
Fair enough. I don't think this requires respinning so what I'll do is that
I'll keep the vote thread open until we have a resolution on the issue.
On Sun, Nov 21, 2021 at 1:29 PM Robert Muir wrote:
> and yes, I think it is reasonable to be a blocker. If we release 9.0,
> promising 2 major
This is of course all possible, but: WHY the heck do this?
Lucene 9.0 will come out likely very soon. After that just update the gradle
file of Solr main and remove the temporary repository (better comment it out).
After that adapt some changes and release Solr 9.0.
>From that point on
> Release of Solr 8.12 It should require the current lucene-solr 8.x branch to
> remove the lucene bits and declare a dependency on lucene 8.11 lucene,
I don't think it'd be particularly hard to move the 8.x line of Solr
to gradle, just like the mainline development is done. Then you could
have
Hi folks-
Is anyone familiar with MultiRangeQuery (found in
o.a.l.sandbox.search)? I was playing around with it recently since it
might be a good fit for a use-case I'm working on for Amazon's Product
Search engine, but it looks like it has a pretty fundamental bug in
how it works. That or I'm
Release of Solr 8.12 It should require the current lucene-solr 8.x branch
to remove the lucene bits and declare a dependency on lucene 8.11 lucene,
that bit shouldn't be too hard if done soon... and the release process for
8.x would not publish a lucene artifact which is likely the harder bit. I
Took a glance at this failure and it looks like the test is creating a
TopScoreDocCollector with a "numHits" of 0 (with this random seed).
Way back in LUCENE-2785, TSDC started requiring > 0 (pushing users to
use TotalHitCountCollector instead of passing 0).
Looks like this run just got really
I dunno, this seems really crazy to me. Splitting out solr into its
own repository and allowing it to be released independently from
lucene has already been done, lots of work :) Why not just move
forwards?
On Sun, Nov 21, 2021 at 8:16 AM Ishan Chattopadhyaya
wrote:
>
>
>
> On Sun, 21 Nov, 2021,
On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, wrote:
> Sorry, I just don't understand the implications of what you are suggesting.
>
> The code in question is lucene+solr combined, and the build system and
> packaging and everything only knows how to do that. So are you forking
> all the lucene
Sorry, I just don't understand the implications of what you are suggesting.
The code in question is lucene+solr combined, and the build system and
packaging and everything only knows how to do that. So are you forking
all the lucene code into the solr repo too?
I don't really understand your
> I don't think the solr PMC should issue Lucene 8.12 either.
I never expressed any intention of doing so. Besides, is it even possible
(ASF policies wise)?
This is a weekend, and I feel bad holding up the 9.0 release (since this is
a blocker). Solr PMC can decide later on Solr's releases, and
I don't think the solr PMC should issue Lucene 8.12 either.
On Sun, Nov 21, 2021 at 7:42 AM Ishan Chattopadhyaya
wrote:
>
> Sounds good, Rob. Should I copy over the branch_8x to the solr repo until we
> have further clarity on the course of action to be taken with Solr releases?
>
> On Sun, 21
Sounds good, Rob. Should I copy over the branch_8x to the solr repo until
we have further clarity on the course of action to be taken with Solr
releases?
On Sun, 21 Nov, 2021, 6:10 pm Robert Muir, wrote:
> Nope, it isn't crazy. I am trying to ensure the backwards
> compatibility that we have is
Nope, it isn't crazy. I am trying to ensure the backwards
compatibility that we have is on solid, sustainable footing before we
release a new version promising double the back compat.
On Sun, Nov 21, 2021 at 7:37 AM Ishan Chattopadhyaya
wrote:
>
> Solr doesn't have backward compatability tests,
Solr doesn't have backward compatability tests, only Lucene has.
That's why I proposed leaving the door open for a Solr 8.12 release based
on already released 8.11 Lucene and not releasing any further 8.x minor
version release of Lucene.
As I said, if that's problematic to do on branch_8x of
and yes, I think it is reasonable to be a blocker. If we release 9.0,
promising 2 major versions of back compat, some of these options get
removed from the table.
On Sun, Nov 21, 2021 at 7:23 AM Robert Muir wrote:
>
> Thanks Ignacio,
>
> I see several choices, but the status quo of the testing
Thanks Ignacio,
I see several choices, but the status quo of the testing is the problem.
One choice is to not make any technical changes, but do something to
prevent lucene from having to be compatible with 20 different versions
:) For example, not supporting 2 major versions back would cut it
Your issue has not been ignored but the problem is that the version of the
blocker has not been added so it doesn't appear in a search for blockers in
Lucene 9 :(
Do we need to discuss this again? I thought we discussed and agreed on
increasing our backwards compatibility. My personal opinion is
Hi,
I fully agree with Robert here.
I originally sent the question about branch_8x because of this. Once we
released Lucene 9.0 wen can't release 8.12, because the index file format will
be brand marked as originating from 8.12 then, which 9.0 will refuse to read.
We can only release 8.11.x
Along the same lines of back compat woes, I'd like to see my blocker
issue about back compat testing addressed in the release candidate,
rather than simply ignored.
https://issues.apache.org/jira/browse/LUCENE-10168
With the 9.0 release, we are attempting to *double* our backwards
compatibility
I agree with Robert here, this makes little sense as there is no tooling in
this repository to release solr without lucene. If it ever happens it will
probably be done outside.
The idea of "leaving a door open" has no justification because it is more
"drawing a door in a wall" and might give
I gave my technical justification: our backwards compatibility testing
doesnt work this way. 9.0 can't have guaranteed back compat with
versions coming in the future. This is lunacy.
On Sun, Nov 21, 2021 at 6:30 AM Ishan Chattopadhyaya
wrote:
>
>
https://www.apache.org/foundation/voting.html#Veto
"To prevent vetoes from being used capriciously, the voter must provide
with the veto a *technical justification* showing why the change is bad
(opens a security exposure, negatively affects performance, *etc.* ). A
veto without a justification
-1 to release lucene 9.0, as long as branch_8x remains.
I know you made a separate thread for this, but it is a real problem.
The problem is that we can't support backwards compatibility like
this: releasing 9.0 then 8.12's and stuff. It isn't how the back
compat testing works, it is completely
I think we should remove this branch.
personally, i'll probably -1 any commit to it. I'll see if i can
automate such an email response with a gmail rule.
we already released lucene 9.0, we can't change backwards
compatibility for some 8.12, same old story, lets move on people.
On Sat, Nov 20,
31 matches
Mail list logo
