Re: What should we do of branch_8x?

[Atri Sharma]

+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 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 copy the ivy output dir
 - delete the lucene stuff from release wizard.

 This is quick and easy. Adapting Gradle for a minor release is too hard.

 Am 21. November 2021 21:34:40 UTC schrieb Noble Paul 
 :
>
> 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 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 with future plans around an 8.12 
>> release?
>>
>> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
>>>
>>> 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 both projects have a clear split point and everybody 
>>> can make sure that the backwards compatibility is handled according to 
>>> project’s needs.
>>>
>>>
>>>
>>> If the Solr 9.0 release is a intermediary point (not all deprecations 
>>> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will 
>>> be the release with many new features and Java 11 as minimum 
>>> requirement.
>>>
>>>
>>>
>>> I would really, really not start and fuck up the release process for 
>>> 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to 
>>> do? Why do this release needs to be called 8.12? It is just a version 
>>> number, so why the heck this big issues? I won’t think that Solr will 
>>> add any major features before Solr 9. So what is your exact problem?
>>>
>>>
>>>
>>> Sorry, but this discussion is complete nonsense. Its just version 
>>> numbers and some hick-hack between two parties that disagree. Keep calm 
>>> and don’t try to make it overcomplicated!
>>>
>>>
>>>
>>> I never said that we should kill or delete branch_8x. It can stay there 
>>> forever. I just suggested to make it read-only and add a note. Unless 
>>> there’s really a need to do some 8.12 release (in which case, I’d fork 
>>> 8.11 branch and move Lucene) I see no reason to act and fuck up the 
>>> repositories of both projects which have now a very clear state.
>>>
>>>
>>>
>>> Uwe
>>>
>>>
>>>
>>> -
>>>
>>> Uwe Schindler
>>>
>>> Achterdiek 19, D-28357 Bremen
>>>
>>> https://www.thetaphi.de
>>>
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> From: Gus Heck 
>>> Sent: Sunday, November 21, 2021 5:05 PM
>>> To: dev 
>>> Subject: Re: What should we do of branch_8x?
>>>
>>>
>>>
>>> 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 think the option should be open assuming 
>>> someone is willing to do that work.What should not be an option is any 
>>> further lucene releases on 8.x  and I'd be very leery of any attempt to 
>>> consume lucene 9.0 on Solr 8.x
>>>
>>>
>>>
>>> The Lucene guarantees are irrelevant unless someone contemplates 
>>> releasing an 8.12 lucene, and I really think that would require a 
>>> positive vote from the Lucene PMC (which sounds very 

Re: What should we do of branch_8x?

[Ishan Chattopadhyaya]

+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.
>> - 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 copy the ivy output dir
>>> - delete the lucene stuff from release wizard.
>>>
>>> This is quick and easy. Adapting Gradle for a minor release is too hard.
>>>
>>> Am 21. November 2021 21:34:40 UTC schrieb Noble Paul <
>>> noble.p...@gmail.com>:

 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 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 with future plans around an 8.12 release?
>
> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
>
>> 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 both projects have a clear split point and
>> everybody can make sure that the backwards compatibility is handled
>> according to project’s needs.
>>
>>
>>
>> If the Solr 9.0 release is a intermediary point (not all deprecations
>> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will 
>> be
>> the release with many new features and Java 11 as minimum requirement.
>>
>>
>>
>> I would really, really not start and fuck up the release process for
>> 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to do?
>> Why do this release needs to be called 8.12? It is just a version number,
>> so why the heck this big issues? I won’t think that Solr will add any 
>> major
>> features before Solr 9. So what is your exact problem?
>>
>>
>>
>> Sorry, but this discussion is complete nonsense. Its just version
>> numbers and some hick-hack between two parties that disagree. Keep calm 
>> and
>> don’t try to make it overcomplicated!
>>
>>
>>
>> I never said that we should kill or delete branch_8x. It can stay
>> there forever. I just suggested to make it read-only and add a note. 
>> Unless
>> there’s really a need to do some 8.12 release (in which case, I’d fork 
>> 8.11
>> branch and move Lucene) I see no reason to act and fuck up the 
>> repositories
>> of both projects which have now a very clear state.
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> https://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Gus Heck 
>> *Sent:* Sunday, November 21, 2021 5:05 PM
>> *To:* dev 
>> *Subject:* Re: What should we do of branch_8x?
>>
>>
>>
>> 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 think the option should be open assuming someone is willing
>> to do that work.What should not be an option is any further lucene 
>> releases
>> on 8.x  and I'd be very leery of any attempt to consume lucene 9.0 on 
>> Solr
>> 8.x
>>
>>
>>
>> The Lucene guarantees are irrelevant unless someone contemplates
>> releasing an 8.12 lucene, and I really think that would require a 
>> positive
>> vote from the Lucene PMC (which sounds very unlikely since I see fingers
>> twitching over the -1 holsters there :) )
>>
>>
>>
>> So while I don't favor deleting the entire solr 8.x branch I 

Re: What should we do of branch_8x?

[Gus Heck]

+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 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 copy the ivy output dir
>> - delete the lucene stuff from release wizard.
>>
>> This is quick and easy. Adapting Gradle for a minor release is too hard.
>>
>> Am 21. November 2021 21:34:40 UTC schrieb Noble Paul <
>> noble.p...@gmail.com>:
>>>
>>> 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 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 with future plans around an 8.12 release?

 On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:

> 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 both projects have a clear split point and
> everybody can make sure that the backwards compatibility is handled
> according to project’s needs.
>
>
>
> If the Solr 9.0 release is a intermediary point (not all deprecations
> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will be
> the release with many new features and Java 11 as minimum requirement.
>
>
>
> I would really, really not start and fuck up the release process for
> 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to do?
> Why do this release needs to be called 8.12? It is just a version number,
> so why the heck this big issues? I won’t think that Solr will add any 
> major
> features before Solr 9. So what is your exact problem?
>
>
>
> Sorry, but this discussion is complete nonsense. Its just version
> numbers and some hick-hack between two parties that disagree. Keep calm 
> and
> don’t try to make it overcomplicated!
>
>
>
> I never said that we should kill or delete branch_8x. It can stay
> there forever. I just suggested to make it read-only and add a note. 
> Unless
> there’s really a need to do some 8.12 release (in which case, I’d fork 
> 8.11
> branch and move Lucene) I see no reason to act and fuck up the 
> repositories
> of both projects which have now a very clear state.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Gus Heck 
> *Sent:* Sunday, November 21, 2021 5:05 PM
> *To:* dev 
> *Subject:* Re: What should we do of branch_8x?
>
>
>
> 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 think the option should be open assuming someone is willing
> to do that work.What should not be an option is any further lucene 
> releases
> on 8.x  and I'd be very leery of any attempt to consume lucene 9.0 on Solr
> 8.x
>
>
>
> The Lucene guarantees are irrelevant unless someone contemplates
> releasing an 8.12 lucene, and I really think that would require a positive
> vote from the Lucene PMC (which sounds very unlikely since I see fingers
> twitching over the -1 holsters there :) )
>
>
>
> So while I don't favor deleting the entire solr 8.x branch I think
> it's now fine to remove lucene from it.
>
>
>
> To make things pretty, one could push the 8.x branch to the solr repo
> AFTER lucene is removed, but that sounds like busy work unless there is
> some formal 

Re: What should we do of branch_8x?

[Noble Paul]

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 copy the ivy output dir
> - delete the lucene stuff from release wizard.
>
> This is quick and easy. Adapting Gradle for a minor release is too hard.
>
> Am 21. November 2021 21:34:40 UTC schrieb Noble Paul  >:
>>
>> 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 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 with future plans around an 8.12 release?
>>>
>>> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
>>>
 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 both projects have a clear split point and everybody
 can make sure that the backwards compatibility is handled according to
 project’s needs.



 If the Solr 9.0 release is a intermediary point (not all deprecations
 removed), release Solr 10.0 four months later, who cares? Solr 9.0 will be
 the release with many new features and Java 11 as minimum requirement.



 I would really, really not start and fuck up the release process for
 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to do?
 Why do this release needs to be called 8.12? It is just a version number,
 so why the heck this big issues? I won’t think that Solr will add any major
 features before Solr 9. So what is your exact problem?



 Sorry, but this discussion is complete nonsense. Its just version
 numbers and some hick-hack between two parties that disagree. Keep calm and
 don’t try to make it overcomplicated!



 I never said that we should kill or delete branch_8x. It can stay there
 forever. I just suggested to make it read-only and add a note. Unless
 there’s really a need to do some 8.12 release (in which case, I’d fork 8.11
 branch and move Lucene) I see no reason to act and fuck up the repositories
 of both projects which have now a very clear state.



 Uwe



 -

 Uwe Schindler

 Achterdiek 19, D-28357 Bremen

 https://www.thetaphi.de

 eMail: u...@thetaphi.de



 *From:* Gus Heck 
 *Sent:* Sunday, November 21, 2021 5:05 PM
 *To:* dev 
 *Subject:* Re: What should we do of branch_8x?



 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 think the option should be open assuming someone is willing
 to do that work.What should not be an option is any further lucene releases
 on 8.x  and I'd be very leery of any attempt to consume lucene 9.0 on Solr
 8.x



 The Lucene guarantees are irrelevant unless someone contemplates
 releasing an 8.12 lucene, and I really think that would require a positive
 vote from the Lucene PMC (which sounds very unlikely since I see fingers
 twitching over the -1 holsters there :) )



 So while I don't favor deleting the entire solr 8.x branch I think it's
 now fine to remove lucene from it.



 To make things pretty, one could push the 8.x branch to the solr repo
 AFTER lucene is removed, but that sounds like busy work unless there is
 some formal or financial need to close the old repo. They are now fully
 separate projects and what solr does with the non-lucene bits is not a
 concern to lucene pmc (though almost all of us are on both committees of
 course, but hat wearing etc..)



 On Sun, Nov 

Re: What should we do of branch_8x?

[Uwe Schindler]

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 copy the ivy output dir
- delete the lucene stuff from release wizard.

This is quick and easy. Adapting Gradle for a minor release is too hard.

Am 21. November 2021 21:34:40 UTC schrieb Noble Paul :
>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 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 with future plans around an 8.12 release?
>>
>> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
>>
>>> 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 both projects have a clear split point and everybody
>>> can make sure that the backwards compatibility is handled according to
>>> project’s needs.
>>>
>>>
>>>
>>> If the Solr 9.0 release is a intermediary point (not all deprecations
>>> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will be
>>> the release with many new features and Java 11 as minimum requirement.
>>>
>>>
>>>
>>> I would really, really not start and fuck up the release process for 8.x!
>>> Why not release 8.11.1 soon, if you have any changes in Solr to do? Why do
>>> this release needs to be called 8.12? It is just a version number, so why
>>> the heck this big issues? I won’t think that Solr will add any major
>>> features before Solr 9. So what is your exact problem?
>>>
>>>
>>>
>>> Sorry, but this discussion is complete nonsense. Its just version numbers
>>> and some hick-hack between two parties that disagree. Keep calm and don’t
>>> try to make it overcomplicated!
>>>
>>>
>>>
>>> I never said that we should kill or delete branch_8x. It can stay there
>>> forever. I just suggested to make it read-only and add a note. Unless
>>> there’s really a need to do some 8.12 release (in which case, I’d fork 8.11
>>> branch and move Lucene) I see no reason to act and fuck up the repositories
>>> of both projects which have now a very clear state.
>>>
>>>
>>>
>>> Uwe
>>>
>>>
>>>
>>> -
>>>
>>> Uwe Schindler
>>>
>>> Achterdiek 19, D-28357 Bremen
>>>
>>> https://www.thetaphi.de
>>>
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> *From:* Gus Heck 
>>> *Sent:* Sunday, November 21, 2021 5:05 PM
>>> *To:* dev 
>>> *Subject:* Re: What should we do of branch_8x?
>>>
>>>
>>>
>>> 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
>>> think the option should be open assuming someone is willing to do that
>>> work.What should not be an option is any further lucene releases on 8.x
>>> and I'd be very leery of any attempt to consume lucene 9.0 on Solr 8.x
>>>
>>>
>>>
>>> The Lucene guarantees are irrelevant unless someone contemplates
>>> releasing an 8.12 lucene, and I really think that would require a positive
>>> vote from the Lucene PMC (which sounds very unlikely since I see fingers
>>> twitching over the -1 holsters there :) )
>>>
>>>
>>>
>>> So while I don't favor deleting the entire solr 8.x branch I think it's
>>> now fine to remove lucene from it.
>>>
>>>
>>>
>>> To make things pretty, one could push the 8.x branch to the solr repo
>>> AFTER lucene is removed, but that sounds like busy work unless there is
>>> some formal or financial need to close the old repo. They are now fully
>>> separate projects and what solr does with the non-lucene bits is not a
>>> concern to lucene pmc (though almost all of us are on both committees of
>>> course, but hat wearing etc..)
>>>
>>>
>>>
>>> On Sun, Nov 21, 2021 at 8:43 AM Robert Muir  wrote:
>>>
>>> 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, 6:31 pm Robert Muir,  wrote:
>>> >>
>>> >> Sorry, I just don't 

Re: What should we do of branch_8x?

[Noble Paul]

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 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 with future plans around an 8.12 release?
>
> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
>
>> 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 both projects have a clear split point and everybody
>> can make sure that the backwards compatibility is handled according to
>> project’s needs.
>>
>>
>>
>> If the Solr 9.0 release is a intermediary point (not all deprecations
>> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will be
>> the release with many new features and Java 11 as minimum requirement.
>>
>>
>>
>> I would really, really not start and fuck up the release process for 8.x!
>> Why not release 8.11.1 soon, if you have any changes in Solr to do? Why do
>> this release needs to be called 8.12? It is just a version number, so why
>> the heck this big issues? I won’t think that Solr will add any major
>> features before Solr 9. So what is your exact problem?
>>
>>
>>
>> Sorry, but this discussion is complete nonsense. Its just version numbers
>> and some hick-hack between two parties that disagree. Keep calm and don’t
>> try to make it overcomplicated!
>>
>>
>>
>> I never said that we should kill or delete branch_8x. It can stay there
>> forever. I just suggested to make it read-only and add a note. Unless
>> there’s really a need to do some 8.12 release (in which case, I’d fork 8.11
>> branch and move Lucene) I see no reason to act and fuck up the repositories
>> of both projects which have now a very clear state.
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> https://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Gus Heck 
>> *Sent:* Sunday, November 21, 2021 5:05 PM
>> *To:* dev 
>> *Subject:* Re: What should we do of branch_8x?
>>
>>
>>
>> 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
>> think the option should be open assuming someone is willing to do that
>> work.What should not be an option is any further lucene releases on 8.x
>> and I'd be very leery of any attempt to consume lucene 9.0 on Solr 8.x
>>
>>
>>
>> The Lucene guarantees are irrelevant unless someone contemplates
>> releasing an 8.12 lucene, and I really think that would require a positive
>> vote from the Lucene PMC (which sounds very unlikely since I see fingers
>> twitching over the -1 holsters there :) )
>>
>>
>>
>> So while I don't favor deleting the entire solr 8.x branch I think it's
>> now fine to remove lucene from it.
>>
>>
>>
>> To make things pretty, one could push the 8.x branch to the solr repo
>> AFTER lucene is removed, but that sounds like busy work unless there is
>> some formal or financial need to close the old repo. They are now fully
>> separate projects and what solr does with the non-lucene bits is not a
>> concern to lucene pmc (though almost all of us are on both committees of
>> course, but hat wearing etc..)
>>
>>
>>
>> On Sun, Nov 21, 2021 at 8:43 AM Robert Muir  wrote:
>>
>> 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, 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 code into the solr repo too?
>> >
>> >
>> > Need to split it up and remove the Lucene code from there in order to
>> be able to release Solr independently. We can do so later (I'm currently on
>> travel), if/when needed.
>> >>
>> >>
>> >> I don't really understand your need to have a branch_8x. we can nuke
>> >> it, and you can do any of this from a branch_8_11 some other day, no?
>> >

Re: What should we do of branch_8x?

[Adrien Grand]

+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 with future plans around an 8.12 release?

On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:

> 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 both projects have a clear split point and everybody
> can make sure that the backwards compatibility is handled according to
> project’s needs.
>
>
>
> If the Solr 9.0 release is a intermediary point (not all deprecations
> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will be
> the release with many new features and Java 11 as minimum requirement.
>
>
>
> I would really, really not start and fuck up the release process for 8.x!
> Why not release 8.11.1 soon, if you have any changes in Solr to do? Why do
> this release needs to be called 8.12? It is just a version number, so why
> the heck this big issues? I won’t think that Solr will add any major
> features before Solr 9. So what is your exact problem?
>
>
>
> Sorry, but this discussion is complete nonsense. Its just version numbers
> and some hick-hack between two parties that disagree. Keep calm and don’t
> try to make it overcomplicated!
>
>
>
> I never said that we should kill or delete branch_8x. It can stay there
> forever. I just suggested to make it read-only and add a note. Unless
> there’s really a need to do some 8.12 release (in which case, I’d fork 8.11
> branch and move Lucene) I see no reason to act and fuck up the repositories
> of both projects which have now a very clear state.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Gus Heck 
> *Sent:* Sunday, November 21, 2021 5:05 PM
> *To:* dev 
> *Subject:* Re: What should we do of branch_8x?
>
>
>
> 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
> think the option should be open assuming someone is willing to do that
> work.What should not be an option is any further lucene releases on 8.x
> and I'd be very leery of any attempt to consume lucene 9.0 on Solr 8.x
>
>
>
> The Lucene guarantees are irrelevant unless someone contemplates releasing
> an 8.12 lucene, and I really think that would require a positive vote from
> the Lucene PMC (which sounds very unlikely since I see fingers twitching
> over the -1 holsters there :) )
>
>
>
> So while I don't favor deleting the entire solr 8.x branch I think it's
> now fine to remove lucene from it.
>
>
>
> To make things pretty, one could push the 8.x branch to the solr repo
> AFTER lucene is removed, but that sounds like busy work unless there is
> some formal or financial need to close the old repo. They are now fully
> separate projects and what solr does with the non-lucene bits is not a
> concern to lucene pmc (though almost all of us are on both committees of
> course, but hat wearing etc..)
>
>
>
> On Sun, Nov 21, 2021 at 8:43 AM Robert Muir  wrote:
>
> 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, 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 code into the solr repo too?
> >
> >
> > Need to split it up and remove the Lucene code from there in order to be
> able to release Solr independently. We can do so later (I'm currently on
> travel), if/when needed.
> >>
> >>
> >> I don't really understand your need to have a branch_8x. we can nuke
> >> it, and you can do any of this from a branch_8_11 some other day, no?
> >
> >
> > I guess we can, just don't know the divergence. Just to be on the safer
> side, don't want to lose access to the branch_8x over a weekend before I or
> persons more knowledgeable (on the differences between the branches) than I
> get a chance to review the situation. Hence, I just copied the branch there
> for the moment.
> >>
> >>
> >> On Sun, Nov 

Re: [VOTE] Release Lucene 9.0.0 RC1

[Adrien Grand]

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 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 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 in
> > half. Another solution would be to release major versions faster so
> > that we churn thru the versions at a more sustainable rate rather than
> > having them pile up.
> >
> > Another option is to technically alter how the testing is done (as
> > suggested on the issue). It could mean that some of them only run
> > nightly or otherwise in jenkins. Which exact tests? I'm not sure, just
> > as long as it becomes reasonable.
> >
> > On Sun, Nov 21, 2021 at 7:18 AM Ignacio Vera  wrote:
> > >
> > > 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 that it is a
> natural step for mature software that it is increasingly used in production
> environments.
> > >
> > > Regarding your concerns in the subject, there is a healthy discussion
> in the issue and there are sound proposals to ease the pain and they can be
> implemented any time, do you think it is still a blocker?
> > >
> > >
> > >
> > > On Sun, Nov 21, 2021 at 12:59 PM Robert Muir  wrote:
> > >>
> > >> 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 guarantees (2 major versions), yet here we are
> > >> discussing insane release strategies that can't be guaranteed/tested
> > >> to work (8.12-after-9.0-etc), here we are with back compat tests
> > >> taking a minute and half on branch_9_0! Imagine how long they will
> > >> take for branch_9_9!
> > >>
> > >> When it comes to more back compat, people are quick to demand more of
> > >> it every time. But when it comes to addressing the necessary issues to
> > >> make it work...crickets.
> > >>
> > >> On Sun, Nov 21, 2021 at 5:11 AM Robert Muir  wrote:
> > >> >
> > >> > -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 cowboy and unsupported.
> > >> >
> > >> > On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand 
> wrote:
> > >> > >
> > >> > > I think we should remove it but I remember it was controversial
> in the past. I'll start a separate thread.
> > >> > >
> > >> > > Le sam. 20 nov. 2021 à 14:38, Uwe Schindler  a
> écrit :
> > >> > >>
> > >> > >> Yes. But we won't have a 8.12 release so I assume the branch_8x
> is dead. Maybe we should dass a note to it's readme or delete it?
> > >> > >>
> > >> > >> Uwe
> > >> > >>
> > >> > >> Am 20. November 2021 13:15:23 UTC schrieb Adrien Grand <
> jpou...@gmail.com>:
> > >> > >>>
> > >> > >>> We need to keep the 8.11 jobs, but I think they can be
> disabled. We typically only enable them when we start discussing doing a
> new patch release?
> > >> > >>>
> > >> > >>> Le sam. 20 nov. 2021 à 12:51, Uwe Schindler 
> a écrit :
> > >> > 
> > >> >  Hi,
> > >> > 
> > >> >  I setup my usual release tester job on Policeman Jenkins and
> it succeeded:
> > >> >  SUCCESS! [0:19:00.801641]
> > >> > 
> > >> >  See here for log:
> https://jenkins.thetaphi.de/job/Lucene-Release-Tester/4/console
> > >> > 
> > >> >  So it looks like technically the release is fine. I will wait
> a bit with my +1, because I wanted to manually check the artifacts and
> javadocs first.
> > >> > 
> > >> >  I also enabled the 9.0 and 9.x builds on Policeman Jenkins
> (sorry for the delay). At the same time I disabled 8.x builds. If Solr
> people still need them we can enable them. But I think the only ones we
> need now are 8.11.x ones, right?
> > >> > 
> > >> >  Uwe
> > >> > 
> > >> >  -
> > >> >  Uwe Schindler
> > >> >  Achterdiek 19, D-28357 Bremen
> 

RE: What should we do of branch_8x?

[Uwe Schindler]

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 both projects have a clear split point and everybody can 
>make sure that the backwards compatibility is handled according to project’s 
>needs. 

 

If the Solr 9.0 release is a intermediary point (not all deprecations removed), 
release Solr 10.0 four months later, who cares? Solr 9.0 will be the release 
with many new features and Java 11 as minimum requirement.

 

I would really, really not start and fuck up the release process for 8.x! Why 
not release 8.11.1 soon, if you have any changes in Solr to do? Why do this 
release needs to be called 8.12? It is just a version number, so why the heck 
this big issues? I won’t think that Solr will add any major features before 
Solr 9. So what is your exact problem?

 

Sorry, but this discussion is complete nonsense. Its just version numbers and 
some hick-hack between two parties that disagree. Keep calm and don’t try to 
make it overcomplicated!

 

I never said that we should kill or delete branch_8x. It can stay there 
forever. I just suggested to make it read-only and add a note. Unless there’s 
really a need to do some 8.12 release (in which case, I’d fork 8.11 branch and 
move Lucene) I see no reason to act and fuck up the repositories of both 
projects which have now a very clear state.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Gus Heck  
Sent: Sunday, November 21, 2021 5:05 PM
To: dev 
Subject: Re: What should we do of branch_8x?

 

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 think the option 
should be open assuming someone is willing to do that work.What should not be 
an option is any further lucene releases on 8.x  and I'd be very leery of any 
attempt to consume lucene 9.0 on Solr 8.x

 

The Lucene guarantees are irrelevant unless someone contemplates releasing an 
8.12 lucene, and I really think that would require a positive vote from the 
Lucene PMC (which sounds very unlikely since I see fingers twitching over the 
-1 holsters there :) )

 

So while I don't favor deleting the entire solr 8.x branch I think it's now 
fine to remove lucene from it. 

 

To make things pretty, one could push the 8.x branch to the solr repo AFTER 
lucene is removed, but that sounds like busy work unless there is some formal 
or financial need to close the old repo. They are now fully separate projects 
and what solr does with the non-lucene bits is not a concern to lucene pmc 
(though almost all of us are on both committees of course, but hat wearing 
etc..)

 

On Sun, Nov 21, 2021 at 8:43 AM Robert Muir mailto:rcm...@gmail.com> > wrote:

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
mailto:ichattopadhy...@gmail.com> > wrote:
>
>
>
> 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 code into the solr repo too?
>
>
> Need to split it up and remove the Lucene code from there in order to be able 
> to release Solr independently. We can do so later (I'm currently on travel), 
> if/when needed.
>>
>>
>> I don't really understand your need to have a branch_8x. we can nuke
>> it, and you can do any of this from a branch_8_11 some other day, no?
>
>
> I guess we can, just don't know the divergence. Just to be on the safer side, 
> don't want to lose access to the branch_8x over a weekend before I or persons 
> more knowledgeable (on the differences between the branches) than I get a 
> chance to review the situation. Hence, I just copied the branch there for the 
> moment.
>>
>>
>> On Sun, Nov 21, 2021 at 7:57 AM Ishan Chattopadhyaya
>> mailto:ichattopadhy...@gmail.com> > wrote:
>> >
>> > > 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 hence I'm 
>> > going to copy this branch_8x over to 

Re: What should we do of branch_8x?

[Dawid Weiss]

> 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 any dependency you can think of. Most of the hard work has been
done and porting the build to 8x should be a couple of hours.

Dawid

On Sun, Nov 21, 2021 at 5:05 PM Gus Heck  wrote:
>
> 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 think 
> the option should be open assuming someone is willing to do that work.What 
> should not be an option is any further lucene releases on 8.x  and I'd be 
> very leery of any attempt to consume lucene 9.0 on Solr 8.x
>
> The Lucene guarantees are irrelevant unless someone contemplates releasing an 
> 8.12 lucene, and I really think that would require a positive vote from the 
> Lucene PMC (which sounds very unlikely since I see fingers twitching over the 
> -1 holsters there :) )
>
> So while I don't favor deleting the entire solr 8.x branch I think it's now 
> fine to remove lucene from it.
>
> To make things pretty, one could push the 8.x branch to the solr repo AFTER 
> lucene is removed, but that sounds like busy work unless there is some formal 
> or financial need to close the old repo. They are now fully separate projects 
> and what solr does with the non-lucene bits is not a concern to lucene pmc 
> (though almost all of us are on both committees of course, but hat wearing 
> etc..)
>
> On Sun, Nov 21, 2021 at 8:43 AM Robert Muir  wrote:
>>
>> 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, 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 code into the solr repo too?
>> >
>> >
>> > Need to split it up and remove the Lucene code from there in order to be 
>> > able to release Solr independently. We can do so later (I'm currently on 
>> > travel), if/when needed.
>> >>
>> >>
>> >> I don't really understand your need to have a branch_8x. we can nuke
>> >> it, and you can do any of this from a branch_8_11 some other day, no?
>> >
>> >
>> > I guess we can, just don't know the divergence. Just to be on the safer 
>> > side, don't want to lose access to the branch_8x over a weekend before I 
>> > or persons more knowledgeable (on the differences between the branches) 
>> > than I get a chance to review the situation. Hence, I just copied the 
>> > branch there for the moment.
>> >>
>> >>
>> >> On Sun, Nov 21, 2021 at 7:57 AM Ishan Chattopadhyaya
>> >>  wrote:
>> >> >
>> >> > > 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 
>> >> > hence I'm going to copy this branch_8x over to Solr repo's 
>> >> > "lucene-solr/branch_8x" branch.
>> >> >
>> >> >
>> >> > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir  wrote:
>> >> >>
>> >> >> 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 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 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, 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.
>> >> >> >> >
>> >> >> >> 

Anyone familiar (or use) MultiRangeQuery?

[Greg Miller]

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 completely mis-understanding what the query
is meant to do.

My understanding is that this query should consider documents to be a
match if they contain a point that is found in _any_ of the ranges
represented by this query (i.e., it's a disjunction over a set of
query ranges). But... it appears that the query incorrectly considers
a document to be a match if its point matches on any single dimension
of any range (where it should be requiring all dimensions in a
particular range to match).

I added a unit test to demonstrate this bug along with a proposed fix
over here: https://github.com/apache/lucene/pull/437

If anyone is familiar with this query (or better yet, uses it), I'd be
really interested in your input.

Cheers,
-Greg

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: What should we do of branch_8x?

[Gus Heck]

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
think the option should be open assuming someone is willing to do that
work.What should not be an option is any further lucene releases on 8.x
and I'd be very leery of any attempt to consume lucene 9.0 on Solr 8.x

The Lucene guarantees are irrelevant unless someone contemplates releasing
an 8.12 lucene, and I really think that would require a positive vote from
the Lucene PMC (which sounds very unlikely since I see fingers twitching
over the -1 holsters there :) )

So while I don't favor deleting the entire solr 8.x branch I think it's now
fine to remove lucene from it.

To make things pretty, one could push the 8.x branch to the solr repo AFTER
lucene is removed, but that sounds like busy work unless there is some
formal or financial need to close the old repo. They are now fully separate
projects and what solr does with the non-lucene bits is not a concern to
lucene pmc (though almost all of us are on both committees of course, but
hat wearing etc..)

On Sun, Nov 21, 2021 at 8:43 AM Robert Muir  wrote:

> 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, 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 code into the solr repo too?
> >
> >
> > Need to split it up and remove the Lucene code from there in order to be
> able to release Solr independently. We can do so later (I'm currently on
> travel), if/when needed.
> >>
> >>
> >> I don't really understand your need to have a branch_8x. we can nuke
> >> it, and you can do any of this from a branch_8_11 some other day, no?
> >
> >
> > I guess we can, just don't know the divergence. Just to be on the safer
> side, don't want to lose access to the branch_8x over a weekend before I or
> persons more knowledgeable (on the differences between the branches) than I
> get a chance to review the situation. Hence, I just copied the branch there
> for the moment.
> >>
> >>
> >> On Sun, Nov 21, 2021 at 7:57 AM Ishan Chattopadhyaya
> >>  wrote:
> >> >
> >> > > 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 hence
> I'm going to copy this branch_8x over to Solr repo's
> "lucene-solr/branch_8x" branch.
> >> >
> >> >
> >> > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir  wrote:
> >> >>
> >> >> 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 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 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, 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
> lucene-solr, then we can do so in the solr repo. If some urgent action to
> nuke the branch is to be taken, please give some time to explore
> alternatives that affect Solr's developement.
> >> >> >> >
> >> >> >> > Holding up Lucene 9.0 release for removal of branch_8x is
> lunacy, not the continued existence of this branch in the shared repo,
> since a future course of action should be deliberated upon before nuking
> the branch.
> >> >> >> >
> >> >> >> > On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler, 
> wrote:
> >> >> >> >>
> >> >> >> >> Hi,
> >> >> >> >>
> >> >> >> >> I fully agree with Robert here.
> >> >> >> >>
> >> >> >> >> I originally sent the 

Re: [JENKINS] Lucene » Lucene-Check-main - Build # 3872 - Unstable!

[Greg Miller]

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 unlucky with the random value it
picked up for numHits, but I'll go ahead and tweak the test to make
sure numHits is at least 1.

Cheers,
-Greg

On Sat, Nov 20, 2021 at 4:44 PM Apache Jenkins Server
 wrote:
>
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-main/3872/
>
> 1 tests failed.
> FAILED:  
> org.apache.lucene.sandbox.search.TestCombinedFieldQuery.testScoringWithMultipleFieldTermsMatch
>
> Error Message:
> java.lang.IllegalArgumentException: numHits must be > 0; please use 
> TotalHitCountCollector if you just need the total hit count
>
> Stack Trace:
> java.lang.IllegalArgumentException: numHits must be > 0; please use 
> TotalHitCountCollector if you just need the total hit count
> at 
> __randomizedtesting.SeedInfo.seed([25A4846FCF0B6C50:2E6067174DDBB654]:0)
> at 
> org.apache.lucene.search.TopScoreDocCollector.create(TopScoreDocCollector.java:237)
> at 
> org.apache.lucene.search.TopScoreDocCollector.create(TopScoreDocCollector.java:226)
> at 
> org.apache.lucene.sandbox.search.TestCombinedFieldQuery.testScoringWithMultipleFieldTermsMatch(TestCombinedFieldQuery.java:238)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:44)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:45)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
> at 
> 

Re: What should we do of branch_8x?

[Robert Muir]

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, 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 code into the solr repo too?
>
>
> Need to split it up and remove the Lucene code from there in order to be able 
> to release Solr independently. We can do so later (I'm currently on travel), 
> if/when needed.
>>
>>
>> I don't really understand your need to have a branch_8x. we can nuke
>> it, and you can do any of this from a branch_8_11 some other day, no?
>
>
> I guess we can, just don't know the divergence. Just to be on the safer side, 
> don't want to lose access to the branch_8x over a weekend before I or persons 
> more knowledgeable (on the differences between the branches) than I get a 
> chance to review the situation. Hence, I just copied the branch there for the 
> moment.
>>
>>
>> On Sun, Nov 21, 2021 at 7:57 AM Ishan Chattopadhyaya
>>  wrote:
>> >
>> > > 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 hence I'm 
>> > going to copy this branch_8x over to Solr repo's "lucene-solr/branch_8x" 
>> > branch.
>> >
>> >
>> > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir  wrote:
>> >>
>> >> 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 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 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, 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 lucene-solr, 
>> >> >> > then we can do so in the solr repo. If some urgent action to nuke 
>> >> >> > the branch is to be taken, please give some time to explore 
>> >> >> > alternatives that affect Solr's developement.
>> >> >> >
>> >> >> > Holding up Lucene 9.0 release for removal of branch_8x is lunacy, 
>> >> >> > not the continued existence of this branch in the shared repo, since 
>> >> >> > a future course of action should be deliberated upon before nuking 
>> >> >> > the branch.
>> >> >> >
>> >> >> > On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler,  
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> 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 which is not allowed to have index 
>> >> >> >> format changes and minor version numbers are not persisted.
>> >> >> >>
>> >> >> >> So -1 to release a 8.12 an time in future. If you still want one, 
>> >> >> >> hold 9.0 release and add precautions for this.
>> >> >> >>
>> >> >> >> Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just 
>> >> >> >> add Bugfixes. This also applies to Solr. Later this is decoupled, 
>> >> >> >> so Solr 9.1234 may use Lucene 10.4711.
>> >> >> >>
>> >> >> >> As said before: let's close branch 8.x and add protection to it in 
>> >> >> >> GitHub. Anybox may merge Bugfixes directly from Solr or Lucene main 
>> >> >> >> I to branch_8_11. I see no problem. Just no index changes!
>> >> >> >>
>> >> >> >> Uwe
>> >> >> >>
>> >> >> >> Am 21. November 2021 11:51:34 UTC schrieb Robert Muir 
>> >> >> >> :
>> >> >> >>>
>> >> >> >>> I gave my technical justification: our backwards compatibility 
>> >> >> >>> testing
>> >> >> >>> doesnt work this way. 9.0 can't have guaranteed back compat with
>> >> >> 

Re: What should we do of branch_8x?

[Ishan Chattopadhyaya]

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 code into the solr repo too?
>

Need to split it up and remove the Lucene code from there in order to be
able to release Solr independently. We can do so later (I'm currently on
travel), if/when needed.

>
> I don't really understand your need to have a branch_8x. we can nuke
> it, and you can do any of this from a branch_8_11 some other day, no?
>

I guess we can, just don't know the divergence. Just to be on the safer
side, don't want to lose access to the branch_8x over a weekend before I or
persons more knowledgeable (on the differences between the branches) than I
get a chance to review the situation. Hence, I just copied the branch there
for the moment.

>
> On Sun, Nov 21, 2021 at 7:57 AM Ishan Chattopadhyaya
>  wrote:
> >
> > > 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 hence I'm
> going to copy this branch_8x over to Solr repo's "lucene-solr/branch_8x"
> branch.
> >
> >
> > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir  wrote:
> >>
> >> 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 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 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, 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
> lucene-solr, then we can do so in the solr repo. If some urgent action to
> nuke the branch is to be taken, please give some time to explore
> alternatives that affect Solr's developement.
> >> >> >
> >> >> > Holding up Lucene 9.0 release for removal of branch_8x is lunacy,
> not the continued existence of this branch in the shared repo, since a
> future course of action should be deliberated upon before nuking the branch.
> >> >> >
> >> >> > On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler, 
> wrote:
> >> >> >>
> >> >> >> 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 which is not allowed to have index
> format changes and minor version numbers are not persisted.
> >> >> >>
> >> >> >> So -1 to release a 8.12 an time in future. If you still want one,
> hold 9.0 release and add precautions for this.
> >> >> >>
> >> >> >> Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just
> add Bugfixes. This also applies to Solr. Later this is decoupled, so Solr
> 9.1234 may use Lucene 10.4711.
> >> >> >>
> >> >> >> As said before: let's close branch 8.x and add protection to it
> in GitHub. Anybox may merge Bugfixes directly from Solr or Lucene main I to
> branch_8_11. I see no problem. Just no index changes!
> >> >> >>
> >> >> >> Uwe
> >> >> >>
> >> >> >> Am 21. November 2021 11:51:34 UTC schrieb Robert Muir <
> rcm...@gmail.com>:
> >> >> >>>
> >> >> >>> 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 is invalid and has no weight."
> >> >> 
> >> >>   On Sun, 21 Nov, 2021, 3:30 

Re: What should we do of branch_8x?

[Robert Muir]

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 need to have a branch_8x. we can nuke
it, and you can do any of this from a branch_8_11 some other day, no?

On Sun, Nov 21, 2021 at 7:57 AM Ishan Chattopadhyaya
 wrote:
>
> > 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 hence I'm going 
> to copy this branch_8x over to Solr repo's "lucene-solr/branch_8x" branch.
>
>
> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir  wrote:
>>
>> 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 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 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, 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 lucene-solr, 
>> >> > then we can do so in the solr repo. If some urgent action to nuke the 
>> >> > branch is to be taken, please give some time to explore alternatives 
>> >> > that affect Solr's developement.
>> >> >
>> >> > Holding up Lucene 9.0 release for removal of branch_8x is lunacy, not 
>> >> > the continued existence of this branch in the shared repo, since a 
>> >> > future course of action should be deliberated upon before nuking the 
>> >> > branch.
>> >> >
>> >> > On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler,  wrote:
>> >> >>
>> >> >> 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 which is not allowed to have index format 
>> >> >> changes and minor version numbers are not persisted.
>> >> >>
>> >> >> So -1 to release a 8.12 an time in future. If you still want one, hold 
>> >> >> 9.0 release and add precautions for this.
>> >> >>
>> >> >> Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just add 
>> >> >> Bugfixes. This also applies to Solr. Later this is decoupled, so Solr 
>> >> >> 9.1234 may use Lucene 10.4711.
>> >> >>
>> >> >> As said before: let's close branch 8.x and add protection to it in 
>> >> >> GitHub. Anybox may merge Bugfixes directly from Solr or Lucene main I 
>> >> >> to branch_8_11. I see no problem. Just no index changes!
>> >> >>
>> >> >> Uwe
>> >> >>
>> >> >> Am 21. November 2021 11:51:34 UTC schrieb Robert Muir 
>> >> >> :
>> >> >>>
>> >> >>> 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 is invalid and 
>> >>  has no weight."
>> >> 
>> >>   On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:
>> >> >
>> >> >
>> >> >  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, 2021 at 9:29 AM Adrien Grand  
>> >> > wrote:
>> >> >>
>> >> >>

Re: What should we do of branch_8x?

[Ishan Chattopadhyaya]

> 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 hence I'm
going to copy this branch_8x over to Solr repo's "lucene-solr/branch_8x"
branch.


On Sun, Nov 21, 2021 at 6:14 PM Robert Muir  wrote:

> 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 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 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, 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 lucene-solr,
> then we can do so in the solr repo. If some urgent action to nuke the
> branch is to be taken, please give some time to explore alternatives that
> affect Solr's developement.
> >> >
> >> > Holding up Lucene 9.0 release for removal of branch_8x is lunacy, not
> the continued existence of this branch in the shared repo, since a future
> course of action should be deliberated upon before nuking the branch.
> >> >
> >> > On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler,  wrote:
> >> >>
> >> >> 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 which is not allowed to have index format
> changes and minor version numbers are not persisted.
> >> >>
> >> >> So -1 to release a 8.12 an time in future. If you still want one,
> hold 9.0 release and add precautions for this.
> >> >>
> >> >> Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just
> add Bugfixes. This also applies to Solr. Later this is decoupled, so Solr
> 9.1234 may use Lucene 10.4711.
> >> >>
> >> >> As said before: let's close branch 8.x and add protection to it in
> GitHub. Anybox may merge Bugfixes directly from Solr or Lucene main I to
> branch_8_11. I see no problem. Just no index changes!
> >> >>
> >> >> Uwe
> >> >>
> >> >> Am 21. November 2021 11:51:34 UTC schrieb Robert Muir <
> rcm...@gmail.com>:
> >> >>>
> >> >>> 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 is invalid and has no weight."
> >> 
> >>   On Sun, 21 Nov, 2021, 3:30 pm Robert Muir, 
> wrote:
> >> >
> >> >
> >> >  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, 2021 at 9:29 AM Adrien Grand 
> wrote:
> >> >>
> >> >>
> >> >>  Uwe brought up the question on a the vote thread: we are not
> going to do a 8.12 release, so what should we do of branch_8x?
> >> >
> >> > 
> >> >  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> >  For additional commands, e-mail: dev-h...@lucene.apache.org
> >> >
> >> >>> 
> >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >> >>>
> >> >> --
> >> >> Uwe Schindler
> >> >> Achterdiek 19, 28357 Bremen
> >> >> https://www.thetaphi.de
>

Re: What should we do of branch_8x?

[Robert Muir]

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 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 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, 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 lucene-solr, then 
>> > we can do so in the solr repo. If some urgent action to nuke the branch is 
>> > to be taken, please give some time to explore alternatives that affect 
>> > Solr's developement.
>> >
>> > Holding up Lucene 9.0 release for removal of branch_8x is lunacy, not the 
>> > continued existence of this branch in the shared repo, since a future 
>> > course of action should be deliberated upon before nuking the branch.
>> >
>> > On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler,  wrote:
>> >>
>> >> 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 which is not allowed to have index format 
>> >> changes and minor version numbers are not persisted.
>> >>
>> >> So -1 to release a 8.12 an time in future. If you still want one, hold 
>> >> 9.0 release and add precautions for this.
>> >>
>> >> Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just add 
>> >> Bugfixes. This also applies to Solr. Later this is decoupled, so Solr 
>> >> 9.1234 may use Lucene 10.4711.
>> >>
>> >> As said before: let's close branch 8.x and add protection to it in 
>> >> GitHub. Anybox may merge Bugfixes directly from Solr or Lucene main I to 
>> >> branch_8_11. I see no problem. Just no index changes!
>> >>
>> >> Uwe
>> >>
>> >> Am 21. November 2021 11:51:34 UTC schrieb Robert Muir :
>> >>>
>> >>> 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 is invalid and has 
>>  no weight."
>> 
>>   On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:
>> >
>> >
>> >  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, 2021 at 9:29 AM Adrien Grand  
>> > wrote:
>> >>
>> >>
>> >>  Uwe brought up the question on a the vote thread: we are not going 
>> >> to do a 8.12 release, so what should we do of branch_8x?
>> >
>> > 
>> >  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >  For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>> >>> 
>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>>
>> >> --
>> >> Uwe Schindler
>> >> Achterdiek 19, 28357 Bremen
>> >> https://www.thetaphi.de

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: What should we do of branch_8x?

[Ishan Chattopadhyaya]

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 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, 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 lucene-solr, then
> we can do so in the solr repo. If some urgent action to nuke the branch is
> to be taken, please give some time to explore alternatives that affect
> Solr's developement.
> >
> > Holding up Lucene 9.0 release for removal of branch_8x is lunacy, not
> the continued existence of this branch in the shared repo, since a future
> course of action should be deliberated upon before nuking the branch.
> >
> > On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler,  wrote:
> >>
> >> 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 which is not allowed to have index format
> changes and minor version numbers are not persisted.
> >>
> >> So -1 to release a 8.12 an time in future. If you still want one, hold
> 9.0 release and add precautions for this.
> >>
> >> Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just add
> Bugfixes. This also applies to Solr. Later this is decoupled, so Solr
> 9.1234 may use Lucene 10.4711.
> >>
> >> As said before: let's close branch 8.x and add protection to it in
> GitHub. Anybox may merge Bugfixes directly from Solr or Lucene main I to
> branch_8_11. I see no problem. Just no index changes!
> >>
> >> Uwe
> >>
> >> Am 21. November 2021 11:51:34 UTC schrieb Robert Muir  >:
> >>>
> >>> 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 is invalid and has no weight."
> 
>   On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:
> >
> >
> >  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, 2021 at 9:29 AM Adrien Grand 
> wrote:
> >>
> >>
> >>  Uwe brought up the question on a the vote thread: we are not going
> to do a 8.12 release, so what should we do of branch_8x?
> >
> > 
> >  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >  For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >>> 
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >> --
> >> Uwe Schindler
> >> Achterdiek 19, 28357 Bremen
> >> https://www.thetaphi.de
>

Re: What should we do of branch_8x?

[Robert Muir]

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, 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 lucene-solr, then we 
> can do so in the solr repo. If some urgent action to nuke the branch is to be 
> taken, please give some time to explore alternatives that affect Solr's 
> developement.
>
> Holding up Lucene 9.0 release for removal of branch_8x is lunacy, not the 
> continued existence of this branch in the shared repo, since a future course 
> of action should be deliberated upon before nuking the branch.
>
> On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler,  wrote:
>>
>> 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 which is not allowed to have index format changes 
>> and minor version numbers are not persisted.
>>
>> So -1 to release a 8.12 an time in future. If you still want one, hold 9.0 
>> release and add precautions for this.
>>
>> Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just add 
>> Bugfixes. This also applies to Solr. Later this is decoupled, so Solr 9.1234 
>> may use Lucene 10.4711.
>>
>> As said before: let's close branch 8.x and add protection to it in GitHub. 
>> Anybox may merge Bugfixes directly from Solr or Lucene main I to 
>> branch_8_11. I see no problem. Just no index changes!
>>
>> Uwe
>>
>> Am 21. November 2021 11:51:34 UTC schrieb Robert Muir :
>>>
>>> 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 is invalid and has no weight."

  On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:
>
>
>  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, 2021 at 9:29 AM Adrien Grand  wrote:
>>
>>
>>  Uwe brought up the question on a the vote thread: we are not going to 
>> do a 8.12 release, so what should we do of branch_8x?
>
> 
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: dev-h...@lucene.apache.org
>
>>> 
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: What should we do of branch_8x?

[Ishan Chattopadhyaya]

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 lucene-solr, then we
can do so in the solr repo. If some urgent action to nuke the branch is to
be taken, please give some time to explore alternatives that affect Solr's
developement.

Holding up Lucene 9.0 release for removal of branch_8x is lunacy, not the
continued existence of this branch in the shared repo, since a future
course of action should be deliberated upon before nuking the branch.

On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler,  wrote:

> 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 which is not allowed to have index format
> changes and minor version numbers are not persisted.
>
> So -1 to release a 8.12 an time in future. If you still want one, hold 9.0
> release and add precautions for this.
>
> Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just add
> Bugfixes. This also applies to Solr. Later this is decoupled, so Solr
> 9.1234 may use Lucene 10.4711.
>
> As said before: let's close branch 8.x and add protection to it in GitHub.
> Anybox may merge Bugfixes directly from Solr or Lucene main I to
> branch_8_11. I see no problem. Just no index changes!
>
> Uwe
>
> Am 21. November 2021 11:51:34 UTC schrieb Robert Muir :
>>
>> 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 is invalid and has no weight."
>>>
>>>  On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:
>>>

  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, 2021 at 9:29 AM Adrien Grand  wrote:

>
>  Uwe brought up the question on a the vote thread: we are not going to do 
> a 8.12 release, so what should we do of branch_8x?
>
 --
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org

 --
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>

Re: [VOTE] Release Lucene 9.0.0 RC1

[Robert Muir]

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 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 in
> half. Another solution would be to release major versions faster so
> that we churn thru the versions at a more sustainable rate rather than
> having them pile up.
>
> Another option is to technically alter how the testing is done (as
> suggested on the issue). It could mean that some of them only run
> nightly or otherwise in jenkins. Which exact tests? I'm not sure, just
> as long as it becomes reasonable.
>
> On Sun, Nov 21, 2021 at 7:18 AM Ignacio Vera  wrote:
> >
> > 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 that it is a 
> > natural step for mature software that it is increasingly used in production 
> > environments.
> >
> > Regarding your concerns in the subject, there is a healthy discussion in 
> > the issue and there are sound proposals to ease the pain and they can be 
> > implemented any time, do you think it is still a blocker?
> >
> >
> >
> > On Sun, Nov 21, 2021 at 12:59 PM Robert Muir  wrote:
> >>
> >> 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 guarantees (2 major versions), yet here we are
> >> discussing insane release strategies that can't be guaranteed/tested
> >> to work (8.12-after-9.0-etc), here we are with back compat tests
> >> taking a minute and half on branch_9_0! Imagine how long they will
> >> take for branch_9_9!
> >>
> >> When it comes to more back compat, people are quick to demand more of
> >> it every time. But when it comes to addressing the necessary issues to
> >> make it work...crickets.
> >>
> >> On Sun, Nov 21, 2021 at 5:11 AM Robert Muir  wrote:
> >> >
> >> > -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 cowboy and unsupported.
> >> >
> >> > On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand  wrote:
> >> > >
> >> > > I think we should remove it but I remember it was controversial in the 
> >> > > past. I'll start a separate thread.
> >> > >
> >> > > Le sam. 20 nov. 2021 à 14:38, Uwe Schindler  a écrit 
> >> > > :
> >> > >>
> >> > >> Yes. But we won't have a 8.12 release so I assume the branch_8x is 
> >> > >> dead. Maybe we should dass a note to it's readme or delete it?
> >> > >>
> >> > >> Uwe
> >> > >>
> >> > >> Am 20. November 2021 13:15:23 UTC schrieb Adrien Grand 
> >> > >> :
> >> > >>>
> >> > >>> We need to keep the 8.11 jobs, but I think they can be disabled. We 
> >> > >>> typically only enable them when we start discussing doing a new 
> >> > >>> patch release?
> >> > >>>
> >> > >>> Le sam. 20 nov. 2021 à 12:51, Uwe Schindler  a 
> >> > >>> écrit :
> >> > 
> >> >  Hi,
> >> > 
> >> >  I setup my usual release tester job on Policeman Jenkins and it 
> >> >  succeeded:
> >> >  SUCCESS! [0:19:00.801641]
> >> > 
> >> >  See here for log: 
> >> >  https://jenkins.thetaphi.de/job/Lucene-Release-Tester/4/console
> >> > 
> >> >  So it looks like technically the release is fine. I will wait a bit 
> >> >  with my +1, because I wanted to manually check the artifacts and 
> >> >  javadocs first.
> >> > 
> >> >  I also enabled the 9.0 and 9.x builds on Policeman Jenkins (sorry 
> >> >  for the delay). At the same time I disabled 8.x builds. If Solr 
> >> >  people still need them we can enable them. But I think the only 
> >> >  ones we need now are 8.11.x ones, right?
> >> > 
> >> >  Uwe
> >> > 
> >> >  -
> >> >  Uwe Schindler
> >> >  Achterdiek 19, D-28357 Bremen
> >> >  https://www.thetaphi.de
> >> >  eMail: u...@thetaphi.de
> >> > 
> >> >  > -Original Message-
> >> >  > From: Adrien Grand 
> >> >  > Sent: Saturday, November 20, 2021 9:25 AM
> >> >  > To: Lucene Dev 
> >> > 

Re: [VOTE] Release Lucene 9.0.0 RC1

[Robert Muir]

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 in
half. Another solution would be to release major versions faster so
that we churn thru the versions at a more sustainable rate rather than
having them pile up.

Another option is to technically alter how the testing is done (as
suggested on the issue). It could mean that some of them only run
nightly or otherwise in jenkins. Which exact tests? I'm not sure, just
as long as it becomes reasonable.

On Sun, Nov 21, 2021 at 7:18 AM Ignacio Vera  wrote:
>
> 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 that it is a 
> natural step for mature software that it is increasingly used in production 
> environments.
>
> Regarding your concerns in the subject, there is a healthy discussion in the 
> issue and there are sound proposals to ease the pain and they can be 
> implemented any time, do you think it is still a blocker?
>
>
>
> On Sun, Nov 21, 2021 at 12:59 PM Robert Muir  wrote:
>>
>> 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 guarantees (2 major versions), yet here we are
>> discussing insane release strategies that can't be guaranteed/tested
>> to work (8.12-after-9.0-etc), here we are with back compat tests
>> taking a minute and half on branch_9_0! Imagine how long they will
>> take for branch_9_9!
>>
>> When it comes to more back compat, people are quick to demand more of
>> it every time. But when it comes to addressing the necessary issues to
>> make it work...crickets.
>>
>> On Sun, Nov 21, 2021 at 5:11 AM Robert Muir  wrote:
>> >
>> > -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 cowboy and unsupported.
>> >
>> > On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand  wrote:
>> > >
>> > > I think we should remove it but I remember it was controversial in the 
>> > > past. I'll start a separate thread.
>> > >
>> > > Le sam. 20 nov. 2021 à 14:38, Uwe Schindler  a écrit :
>> > >>
>> > >> Yes. But we won't have a 8.12 release so I assume the branch_8x is 
>> > >> dead. Maybe we should dass a note to it's readme or delete it?
>> > >>
>> > >> Uwe
>> > >>
>> > >> Am 20. November 2021 13:15:23 UTC schrieb Adrien Grand 
>> > >> :
>> > >>>
>> > >>> We need to keep the 8.11 jobs, but I think they can be disabled. We 
>> > >>> typically only enable them when we start discussing doing a new patch 
>> > >>> release?
>> > >>>
>> > >>> Le sam. 20 nov. 2021 à 12:51, Uwe Schindler  a écrit 
>> > >>> :
>> > 
>> >  Hi,
>> > 
>> >  I setup my usual release tester job on Policeman Jenkins and it 
>> >  succeeded:
>> >  SUCCESS! [0:19:00.801641]
>> > 
>> >  See here for log: 
>> >  https://jenkins.thetaphi.de/job/Lucene-Release-Tester/4/console
>> > 
>> >  So it looks like technically the release is fine. I will wait a bit 
>> >  with my +1, because I wanted to manually check the artifacts and 
>> >  javadocs first.
>> > 
>> >  I also enabled the 9.0 and 9.x builds on Policeman Jenkins (sorry for 
>> >  the delay). At the same time I disabled 8.x builds. If Solr people 
>> >  still need them we can enable them. But I think the only ones we need 
>> >  now are 8.11.x ones, right?
>> > 
>> >  Uwe
>> > 
>> >  -
>> >  Uwe Schindler
>> >  Achterdiek 19, D-28357 Bremen
>> >  https://www.thetaphi.de
>> >  eMail: u...@thetaphi.de
>> > 
>> >  > -Original Message-
>> >  > From: Adrien Grand 
>> >  > Sent: Saturday, November 20, 2021 9:25 AM
>> >  > To: Lucene Dev 
>> >  > Subject: [VOTE] Release Lucene 9.0.0 RC1
>> >  >
>> >  > Please vote for release candidate 1 for Lucene 9.0.0.
>> >  >
>> >  > The artifacts can be downloaded from:
>> >  > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC1-rev-
>> >  > 903ee94dc50643299c15dfa954410f3ee4d62075
>> >  >
>> >  > You can run the smoke tester directly with this command:
>> >  >
>> >  > python3 -u 

Re: [VOTE] Release Lucene 9.0.0 RC1

[Ignacio Vera]

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 that it is a
natural step for mature software that it is increasingly used in production
environments.

Regarding your concerns in the subject, there is a healthy discussion in
the issue and there are sound proposals to ease the pain and they can be
implemented any time, do you think it is still a blocker?



On Sun, Nov 21, 2021 at 12:59 PM Robert Muir  wrote:

> 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 guarantees (2 major versions), yet here we are
> discussing insane release strategies that can't be guaranteed/tested
> to work (8.12-after-9.0-etc), here we are with back compat tests
> taking a minute and half on branch_9_0! Imagine how long they will
> take for branch_9_9!
>
> When it comes to more back compat, people are quick to demand more of
> it every time. But when it comes to addressing the necessary issues to
> make it work...crickets.
>
> On Sun, Nov 21, 2021 at 5:11 AM Robert Muir  wrote:
> >
> > -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 cowboy and unsupported.
> >
> > On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand  wrote:
> > >
> > > I think we should remove it but I remember it was controversial in the
> past. I'll start a separate thread.
> > >
> > > Le sam. 20 nov. 2021 à 14:38, Uwe Schindler  a écrit
> :
> > >>
> > >> Yes. But we won't have a 8.12 release so I assume the branch_8x is
> dead. Maybe we should dass a note to it's readme or delete it?
> > >>
> > >> Uwe
> > >>
> > >> Am 20. November 2021 13:15:23 UTC schrieb Adrien Grand <
> jpou...@gmail.com>:
> > >>>
> > >>> We need to keep the 8.11 jobs, but I think they can be disabled. We
> typically only enable them when we start discussing doing a new patch
> release?
> > >>>
> > >>> Le sam. 20 nov. 2021 à 12:51, Uwe Schindler  a
> écrit :
> > 
> >  Hi,
> > 
> >  I setup my usual release tester job on Policeman Jenkins and it
> succeeded:
> >  SUCCESS! [0:19:00.801641]
> > 
> >  See here for log:
> https://jenkins.thetaphi.de/job/Lucene-Release-Tester/4/console
> > 
> >  So it looks like technically the release is fine. I will wait a bit
> with my +1, because I wanted to manually check the artifacts and javadocs
> first.
> > 
> >  I also enabled the 9.0 and 9.x builds on Policeman Jenkins (sorry
> for the delay). At the same time I disabled 8.x builds. If Solr people
> still need them we can enable them. But I think the only ones we need now
> are 8.11.x ones, right?
> > 
> >  Uwe
> > 
> >  -
> >  Uwe Schindler
> >  Achterdiek 19, D-28357 Bremen
> >  https://www.thetaphi.de
> >  eMail: u...@thetaphi.de
> > 
> >  > -Original Message-
> >  > From: Adrien Grand 
> >  > Sent: Saturday, November 20, 2021 9:25 AM
> >  > To: Lucene Dev 
> >  > Subject: [VOTE] Release Lucene 9.0.0 RC1
> >  >
> >  > Please vote for release candidate 1 for Lucene 9.0.0.
> >  >
> >  > The artifacts can be downloaded from:
> >  >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC1-rev-
> >  > 903ee94dc50643299c15dfa954410f3ee4d62075
> >  >
> >  > You can run the smoke tester directly with this command:
> >  >
> >  > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >  >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC1-rev-
> >  > 903ee94dc50643299c15dfa954410f3ee4d62075
> >  >
> >  > The vote will be open until 2021-11-24 09:00 UTC.
> >  >
> >  > [ ] +1  approve
> >  > [ ] +0  no opinion
> >  > [ ] -1  disapprove (and reason why)
> >  >
> >  > Here is my +1
> >  >
> >  > --
> >  > Adrien
> >  >
> >  >
> -
> >  > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >  > For additional commands, e-mail: dev-h...@lucene.apache.org
> > 
> > 
> > 
> -
> >  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >  For additional commands, e-mail: dev-h...@lucene.apache.org
> > 
> > >> --
> > >> Uwe Schindler
> > >> Achterdiek 

Re: What should we do of branch_8x?

[Uwe Schindler]

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 which is not allowed to have index format changes 
and minor version numbers are not persisted.

So -1 to release a 8.12 an time in future. If you still want one, hold 9.0 
release and add precautions for this.

Imho. Let's stop releasing 8.12 or later for Lucene/Solr and just add Bugfixes. 
This also applies to Solr. Later this is decoupled, so Solr 9.1234 may use 
Lucene 10.4711.

As said before: let's close branch 8.x and add protection to it in GitHub. 
Anybox may merge Bugfixes directly from Solr or Lucene main I to branch_8_11. I 
see no problem. Just no index changes!

Uwe

Am 21. November 2021 11:51:34 UTC schrieb Robert Muir :
>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 is invalid and has no weight."
>>
>> On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:
>>>
>>> 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, 2021 at 9:29 AM Adrien Grand  wrote:
>>> >
>>> > Uwe brought up the question on a the vote thread: we are not going to do 
>>> > a 8.12 release, so what should we do of branch_8x?
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org
>

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: [VOTE] Release Lucene 9.0.0 RC1

[Robert Muir]

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 guarantees (2 major versions), yet here we are
discussing insane release strategies that can't be guaranteed/tested
to work (8.12-after-9.0-etc), here we are with back compat tests
taking a minute and half on branch_9_0! Imagine how long they will
take for branch_9_9!

When it comes to more back compat, people are quick to demand more of
it every time. But when it comes to addressing the necessary issues to
make it work...crickets.

On Sun, Nov 21, 2021 at 5:11 AM Robert Muir  wrote:
>
> -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 cowboy and unsupported.
>
> On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand  wrote:
> >
> > I think we should remove it but I remember it was controversial in the 
> > past. I'll start a separate thread.
> >
> > Le sam. 20 nov. 2021 à 14:38, Uwe Schindler  a écrit :
> >>
> >> Yes. But we won't have a 8.12 release so I assume the branch_8x is dead. 
> >> Maybe we should dass a note to it's readme or delete it?
> >>
> >> Uwe
> >>
> >> Am 20. November 2021 13:15:23 UTC schrieb Adrien Grand :
> >>>
> >>> We need to keep the 8.11 jobs, but I think they can be disabled. We 
> >>> typically only enable them when we start discussing doing a new patch 
> >>> release?
> >>>
> >>> Le sam. 20 nov. 2021 à 12:51, Uwe Schindler  a écrit :
> 
>  Hi,
> 
>  I setup my usual release tester job on Policeman Jenkins and it 
>  succeeded:
>  SUCCESS! [0:19:00.801641]
> 
>  See here for log: 
>  https://jenkins.thetaphi.de/job/Lucene-Release-Tester/4/console
> 
>  So it looks like technically the release is fine. I will wait a bit with 
>  my +1, because I wanted to manually check the artifacts and javadocs 
>  first.
> 
>  I also enabled the 9.0 and 9.x builds on Policeman Jenkins (sorry for 
>  the delay). At the same time I disabled 8.x builds. If Solr people still 
>  need them we can enable them. But I think the only ones we need now are 
>  8.11.x ones, right?
> 
>  Uwe
> 
>  -
>  Uwe Schindler
>  Achterdiek 19, D-28357 Bremen
>  https://www.thetaphi.de
>  eMail: u...@thetaphi.de
> 
>  > -Original Message-
>  > From: Adrien Grand 
>  > Sent: Saturday, November 20, 2021 9:25 AM
>  > To: Lucene Dev 
>  > Subject: [VOTE] Release Lucene 9.0.0 RC1
>  >
>  > Please vote for release candidate 1 for Lucene 9.0.0.
>  >
>  > The artifacts can be downloaded from:
>  > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC1-rev-
>  > 903ee94dc50643299c15dfa954410f3ee4d62075
>  >
>  > You can run the smoke tester directly with this command:
>  >
>  > python3 -u dev-tools/scripts/smokeTestRelease.py \
>  > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC1-rev-
>  > 903ee94dc50643299c15dfa954410f3ee4d62075
>  >
>  > The vote will be open until 2021-11-24 09:00 UTC.
>  >
>  > [ ] +1  approve
>  > [ ] +0  no opinion
>  > [ ] -1  disapprove (and reason why)
>  >
>  > Here is my +1
>  >
>  > --
>  > Adrien
>  >
>  > -
>  > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  > For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>  For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> >> --
> >> Uwe Schindler
> >> Achterdiek 19, 28357 Bremen
> >> https://www.thetaphi.de

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: What should we do of branch_8x?

[Ignacio Vera]

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 false expectations.

+1 to remove the branch.

On Sun, Nov 21, 2021 at 12:52 PM Robert Muir  wrote:

> 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 is invalid and has no weight."
> >
> > On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:
> >>
> >> 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, 2021 at 9:29 AM Adrien Grand  wrote:
> >> >
> >> > Uwe brought up the question on a the vote thread: we are not going to
> do a 8.12 release, so what should we do of branch_8x?
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: What should we do of branch_8x?

[Robert Muir]

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 is invalid and has no weight."
>
> On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:
>>
>> 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, 2021 at 9:29 AM Adrien Grand  wrote:
>> >
>> > Uwe brought up the question on a the vote thread: we are not going to do a 
>> > 8.12 release, so what should we do of branch_8x?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: What should we do of branch_8x?

[Ishan Chattopadhyaya]

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 is invalid and has no weight."

On Sun, 21 Nov, 2021, 3:30 pm Robert Muir,  wrote:

> 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, 2021 at 9:29 AM Adrien Grand  wrote:
> >
> > Uwe brought up the question on a the vote thread: we are not going to do
> a 8.12 release, so what should we do of branch_8x?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene 9.0.0 RC1

[Robert Muir]

-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 cowboy and unsupported.

On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand  wrote:
>
> I think we should remove it but I remember it was controversial in the past. 
> I'll start a separate thread.
>
> Le sam. 20 nov. 2021 à 14:38, Uwe Schindler  a écrit :
>>
>> Yes. But we won't have a 8.12 release so I assume the branch_8x is dead. 
>> Maybe we should dass a note to it's readme or delete it?
>>
>> Uwe
>>
>> Am 20. November 2021 13:15:23 UTC schrieb Adrien Grand :
>>>
>>> We need to keep the 8.11 jobs, but I think they can be disabled. We 
>>> typically only enable them when we start discussing doing a new patch 
>>> release?
>>>
>>> Le sam. 20 nov. 2021 à 12:51, Uwe Schindler  a écrit :

 Hi,

 I setup my usual release tester job on Policeman Jenkins and it succeeded:
 SUCCESS! [0:19:00.801641]

 See here for log: 
 https://jenkins.thetaphi.de/job/Lucene-Release-Tester/4/console

 So it looks like technically the release is fine. I will wait a bit with 
 my +1, because I wanted to manually check the artifacts and javadocs first.

 I also enabled the 9.0 and 9.x builds on Policeman Jenkins (sorry for the 
 delay). At the same time I disabled 8.x builds. If Solr people still need 
 them we can enable them. But I think the only ones we need now are 8.11.x 
 ones, right?

 Uwe

 -
 Uwe Schindler
 Achterdiek 19, D-28357 Bremen
 https://www.thetaphi.de
 eMail: u...@thetaphi.de

 > -Original Message-
 > From: Adrien Grand 
 > Sent: Saturday, November 20, 2021 9:25 AM
 > To: Lucene Dev 
 > Subject: [VOTE] Release Lucene 9.0.0 RC1
 >
 > Please vote for release candidate 1 for Lucene 9.0.0.
 >
 > The artifacts can be downloaded from:
 > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC1-rev-
 > 903ee94dc50643299c15dfa954410f3ee4d62075
 >
 > You can run the smoke tester directly with this command:
 >
 > python3 -u dev-tools/scripts/smokeTestRelease.py \
 > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC1-rev-
 > 903ee94dc50643299c15dfa954410f3ee4d62075
 >
 > The vote will be open until 2021-11-24 09:00 UTC.
 >
 > [ ] +1  approve
 > [ ] +0  no opinion
 > [ ] -1  disapprove (and reason why)
 >
 > Here is my +1
 >
 > --
 > Adrien
 >
 > -
 > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 > For additional commands, e-mail: dev-h...@lucene.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: What should we do of branch_8x?

[Robert Muir]

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, 2021 at 9:29 AM Adrien Grand  wrote:
>
> Uwe brought up the question on a the vote thread: we are not going to do a 
> 8.12 release, so what should we do of branch_8x?

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org