Mailing List Archive

1 2  View All
Re: What should we do of branch_8x? [ In reply to ]
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 <uwe@thetaphi.de> 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.paul@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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
>>>>
>>>>
>>>>
>>>> *From:* Gus Heck <gus.heck@gmail.com>
>>>> *Sent:* Sunday, November 21, 2021 5:05 PM
>>>> *To:* dev <dev@lucene.apache.org>
>>>> *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 <rcmuir@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
>>>> <ichattopadhyaya@gmail.com> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com> 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
>>>> >> <ichattopadhyaya@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 Solr repo's
>>>> "lucene-solr/branch_8x" branch.
>>>> >> >
>>>> >> >
>>>> >> > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir <rcmuir@gmail.com>
>>>> 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
>>>> >> >> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com>
>>>> 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
>>>> >> >> >> <ichattopadhyaya@gmail.com> 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, <
>>>> uwe@thetaphi.de> 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 <
>>>> rcmuir@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
>>>> >> >> >> >>> <ichattopadhyaya@gmail.com> 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, <
>>>> rcmuir@gmail.com> 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 <
>>>> jpountz@gmail.com> 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-unsubscribe@lucene.apache.org
>>>> >> >> >> >>>>> For additional commands, e-mail:
>>>> dev-help@lucene.apache.org
>>>> >> >> >> >>>>>
>>>> >> >> >> >>> ________________________________
>>>> >> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >> >> >> >>> For additional commands, e-mail:
>>>> dev-help@lucene.apache.org
>>>> >> >> >> >>>
>>>> >> >> >> >> --
>>>> >> >> >> >> Uwe Schindler
>>>> >> >> >> >> Achterdiek 19, 28357 Bremen
>>>> >> >> >> >> https://www.thetaphi.de
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> http://www.needhamsoftware.com (work)
>>>>
>>>> http://www.the111shift.com (play)
>>>>
>>>
>>>
>>> --
>>> Adrien
>>>
>> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>
Re: What should we do of branch_8x? [ In reply to ]
+1 to uwe's suggestion

On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.paul@gmail.com> 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 <uwe@thetaphi.de> 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.paul@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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
>>>>>
>>>>>
>>>>>
>>>>> *From:* Gus Heck <gus.heck@gmail.com>
>>>>> *Sent:* Sunday, November 21, 2021 5:05 PM
>>>>> *To:* dev <dev@lucene.apache.org>
>>>>> *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 <rcmuir@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
>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com> 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
>>>>> >> <ichattopadhyaya@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 Solr repo's
>>>>> "lucene-solr/branch_8x" branch.
>>>>> >> >
>>>>> >> >
>>>>> >> > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir <rcmuir@gmail.com>
>>>>> 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
>>>>> >> >> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com>
>>>>> 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
>>>>> >> >> >> <ichattopadhyaya@gmail.com> 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, <
>>>>> uwe@thetaphi.de> 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 <
>>>>> rcmuir@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
>>>>> >> >> >> >>> <ichattopadhyaya@gmail.com> 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, <
>>>>> rcmuir@gmail.com> 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 <
>>>>> jpountz@gmail.com> 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-unsubscribe@lucene.apache.org
>>>>> >> >> >> >>>>> For additional commands, e-mail:
>>>>> dev-help@lucene.apache.org
>>>>> >> >> >> >>>>>
>>>>> >> >> >> >>> ________________________________
>>>>> >> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >> >> >> >>> For additional commands, e-mail:
>>>>> dev-help@lucene.apache.org
>>>>> >> >> >> >>>
>>>>> >> >> >> >> --
>>>>> >> >> >> >> Uwe Schindler
>>>>> >> >> >> >> Achterdiek 19, 28357 Bremen
>>>>> >> >> >> >> https://www.thetaphi.de
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> http://www.needhamsoftware.com (work)
>>>>>
>>>>> http://www.the111shift.com (play)
>>>>>
>>>>
>>>>
>>>> --
>>>> Adrien
>>>>
>>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: What should we do of branch_8x? [ In reply to ]
+1 to Uwe's suggestion

On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com> wrote:

> +1 to uwe's suggestion
>
> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.paul@gmail.com> 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 <uwe@thetaphi.de> 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.paul@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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Gus Heck <gus.heck@gmail.com>
>>>>>> *Sent:* Sunday, November 21, 2021 5:05 PM
>>>>>> *To:* dev <dev@lucene.apache.org>
>>>>>> *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 <rcmuir@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
>>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com>
>>>>>> 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
>>>>>> >> <ichattopadhyaya@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 Solr repo's
>>>>>> "lucene-solr/branch_8x" branch.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir <rcmuir@gmail.com>
>>>>>> 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
>>>>>> >> >> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com>
>>>>>> 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
>>>>>> >> >> >> <ichattopadhyaya@gmail.com> 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, <
>>>>>> uwe@thetaphi.de> 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 <
>>>>>> rcmuir@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
>>>>>> >> >> >> >>> <ichattopadhyaya@gmail.com> 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, <
>>>>>> rcmuir@gmail.com> 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 <
>>>>>> jpountz@gmail.com> 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-unsubscribe@lucene.apache.org
>>>>>> >> >> >> >>>>> For additional commands, e-mail:
>>>>>> dev-help@lucene.apache.org
>>>>>> >> >> >> >>>>>
>>>>>> >> >> >> >>> ________________________________
>>>>>> >> >> >> >>> To unsubscribe, e-mail:
>>>>>> dev-unsubscribe@lucene.apache.org
>>>>>> >> >> >> >>> For additional commands, e-mail:
>>>>>> dev-help@lucene.apache.org
>>>>>> >> >> >> >>>
>>>>>> >> >> >> >> --
>>>>>> >> >> >> >> Uwe Schindler
>>>>>> >> >> >> >> Achterdiek 19, 28357 Bremen
>>>>>> >> >> >> >> https://www.thetaphi.de
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> http://www.needhamsoftware.com (work)
>>>>>>
>>>>>> http://www.the111shift.com (play)
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Adrien
>>>>>
>>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
>>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
Re: What should we do of branch_8x? [ In reply to ]
+1, agree with Uwe.

On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
<ichattopadhyaya@gmail.com> wrote:
>
> +1 to Uwe's suggestion
>
> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com> wrote:
>>
>> +1 to uwe's suggestion
>>
>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.paul@gmail.com> 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 <uwe@thetaphi.de> 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.paul@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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Gus Heck <gus.heck@gmail.com>
>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
>>>>>>> To: dev <dev@lucene.apache.org>
>>>>>>> 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 <rcmuir@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
>>>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com> 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
>>>>>>> >> <ichattopadhyaya@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 Solr repo's "lucene-solr/branch_8x" branch.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir <rcmuir@gmail.com> 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
>>>>>>> >> >> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com> 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
>>>>>>> >> >> >> <ichattopadhyaya@gmail.com> 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, <uwe@thetaphi.de> 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 <rcmuir@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
>>>>>>> >> >> >> >>> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com> 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 <jpountz@gmail.com> 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-unsubscribe@lucene.apache.org
>>>>>>> >> >> >> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>> >> >> >> >>>>>
>>>>>>> >> >> >> >>> ________________________________
>>>>>>> >> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> >> >> >> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>> >> >> >> >>>
>>>>>>> >> >> >> >> --
>>>>>>> >> >> >> >> Uwe Schindler
>>>>>>> >> >> >> >> Achterdiek 19, 28357 Bremen
>>>>>>> >> >> >> >> https://www.thetaphi.de
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> http://www.needhamsoftware.com (work)
>>>>>>>
>>>>>>> http://www.the111shift.com (play)
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Adrien
>>>>
>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de
>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)

--
Regards,

Atri
Apache Concerted

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: What should we do of branch_8x? [ In reply to ]
+1 to remove / lock branch_8x in the lucene-solr repo, i.e. there will not be an 8.12 release by Lucene PMC.

Whether Solr needs to release an 8.12 from own repos or not can be discussed in dev@solr if/when needed. So far there is only loose talk, and I think Solr PMC's energy should be devoted to the Solr 9.0 release.

Jan

> 22. nov. 2021 kl. 08:28 skrev Atri Sharma <atri@apache.org>:
>
> +1, agree with Uwe.
>
> On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
> <ichattopadhyaya@gmail.com> wrote:
>>
>> +1 to Uwe's suggestion
>>
>> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com> wrote:
>>>
>>> +1 to uwe's suggestion
>>>
>>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.paul@gmail.com> 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 <uwe@thetaphi.de> 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.paul@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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Gus Heck <gus.heck@gmail.com>
>>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
>>>>>>>> To: dev <dev@lucene.apache.org>
>>>>>>>> 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 <rcmuir@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
>>>>>>>> <ichattopadhyaya@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com> 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
>>>>>>>>>> <ichattopadhyaya@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 Solr repo's "lucene-solr/branch_8x" branch.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir <rcmuir@gmail.com> 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
>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com> 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
>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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, <uwe@thetaphi.de> 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 <rcmuir@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
>>>>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com> 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 <jpountz@gmail.com> 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-unsubscribe@lucene.apache.org
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen
>>>>>>>>>>>>>>>> https://www.thetaphi.de
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> http://www.needhamsoftware.com (work)
>>>>>>>>
>>>>>>>> http://www.the111shift.com (play)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Adrien
>>>>>
>>>>> --
>>>>> Uwe Schindler
>>>>> Achterdiek 19, 28357 Bremen
>>>>> https://www.thetaphi.de
>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>
> --
> Regards,
>
> Atri
> Apache Concerted
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: What should we do of branch_8x? [ In reply to ]
It looks like there is now general agreement on removing branch_8x?

I wonder if we should actually remove it, which is prone to
re-creating the branch by mistake, vs. replacing the content of the
repository with a README that says that this branch is no longer under
development like we did for the `master` branch.

On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan.asf@cominvent.com> wrote:
>
> +1 to remove / lock branch_8x in the lucene-solr repo, i.e. there will not be an 8.12 release by Lucene PMC.
>
> Whether Solr needs to release an 8.12 from own repos or not can be discussed in dev@solr if/when needed. So far there is only loose talk, and I think Solr PMC's energy should be devoted to the Solr 9.0 release.
>
> Jan
>
> > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <atri@apache.org>:
> >
> > +1, agree with Uwe.
> >
> > On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
> > <ichattopadhyaya@gmail.com> wrote:
> >>
> >> +1 to Uwe's suggestion
> >>
> >> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com> wrote:
> >>>
> >>> +1 to uwe's suggestion
> >>>
> >>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.paul@gmail.com> 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 <uwe@thetaphi.de> 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.paul@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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> From: Gus Heck <gus.heck@gmail.com>
> >>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
> >>>>>>>> To: dev <dev@lucene.apache.org>
> >>>>>>>> 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 <rcmuir@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
> >>>>>>>> <ichattopadhyaya@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com> 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
> >>>>>>>>>> <ichattopadhyaya@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 Solr repo's "lucene-solr/branch_8x" branch.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir <rcmuir@gmail.com> 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
> >>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com> 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
> >>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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, <uwe@thetaphi.de> 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 <rcmuir@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
> >>>>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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, <rcmuir@gmail.com> 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 <jpountz@gmail.com> 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-unsubscribe@lucene.apache.org
> >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ________________________________
> >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Uwe Schindler
> >>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen
> >>>>>>>>>>>>>>>> https://www.thetaphi.de
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> http://www.needhamsoftware.com (work)
> >>>>>>>>
> >>>>>>>> http://www.the111shift.com (play)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Adrien
> >>>>>
> >>>>> --
> >>>>> Uwe Schindler
> >>>>> Achterdiek 19, 28357 Bremen
> >>>>> https://www.thetaphi.de
> >>>
> >>>
> >>>
> >>> --
> >>> http://www.needhamsoftware.com (work)
> >>> http://www.the111shift.com (play)
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>


--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: What should we do of branch_8x? [ In reply to ]
Hi,

I checked a bit: branch_7x is also still alive and has some accidental commits in it. So maybe we should do the same there.

In general if we change this, don't forget to change github workflows: https://github.com/apache/lucene-solr/blob/master/.github/workflows/ant.yml

Side note: I am missing the .asf.yaml file in the master branch of old repo. Where is this information stored? This file was there also to protect branches from writing (at least in github): https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-BranchProtection

Uwe

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

> -----Original Message-----
> From: Adrien Grand <jpountz@gmail.com>
> Sent: Tuesday, November 23, 2021 2:02 PM
> To: Lucene Dev <dev@lucene.apache.org>
> Subject: Re: What should we do of branch_8x?
>
> It looks like there is now general agreement on removing branch_8x?
>
> I wonder if we should actually remove it, which is prone to
> re-creating the branch by mistake, vs. replacing the content of the
> repository with a README that says that this branch is no longer under
> development like we did for the `master` branch.
>
> On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan.asf@cominvent.com>
> wrote:
> >
> > +1 to remove / lock branch_8x in the lucene-solr repo, i.e. there will not be an
> 8.12 release by Lucene PMC.
> >
> > Whether Solr needs to release an 8.12 from own repos or not can be
> discussed in dev@solr if/when needed. So far there is only loose talk, and I
> think Solr PMC's energy should be devoted to the Solr 9.0 release.
> >
> > Jan
> >
> > > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <atri@apache.org>:
> > >
> > > +1, agree with Uwe.
> > >
> > > On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
> > > <ichattopadhyaya@gmail.com> wrote:
> > >>
> > >> +1 to Uwe's suggestion
> > >>
> > >> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com>
> wrote:
> > >>>
> > >>> +1 to uwe's suggestion
> > >>>
> > >>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.paul@gmail.com>
> 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 <uwe@thetaphi.de>
> 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.paul@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 <jpountz@gmail.com>
> 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
> <uwe@thetaphi.de> 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: uwe@thetaphi.de
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> From: Gus Heck <gus.heck@gmail.com>
> > >>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
> > >>>>>>>> To: dev <dev@lucene.apache.org>
> > >>>>>>>> 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
> <rcmuir@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
> > >>>>>>>> <ichattopadhyaya@gmail.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com>
> 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
> > >>>>>>>>>> <ichattopadhyaya@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 Solr repo's "lucene-solr/branch_8x"
> branch.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir
> <rcmuir@gmail.com> 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
> > >>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> <rcmuir@gmail.com> 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
> > >>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> <uwe@thetaphi.de> 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 <rcmuir@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
> > >>>>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> <rcmuir@gmail.com> 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
> <jpountz@gmail.com> 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-
> unsubscribe@lucene.apache.org
> > >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
> help@lucene.apache.org
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> ________________________________
> > >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-
> unsubscribe@lucene.apache.org
> > >>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
> help@lucene.apache.org
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>> Uwe Schindler
> > >>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen
> > >>>>>>>>>>>>>>>> https://www.thetaphi.de
> > >>>>>>>>
> > >>>>>>>> ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>>
> > >>>>>>>> http://www.needhamsoftware.com (work)
> > >>>>>>>>
> > >>>>>>>> http://www.the111shift.com (play)
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Adrien
> > >>>>>
> > >>>>> --
> > >>>>> Uwe Schindler
> > >>>>> Achterdiek 19, 28357 Bremen
> > >>>>> https://www.thetaphi.de
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> http://www.needhamsoftware.com (work)
> > >>> http://www.the111shift.com (play)
> > >
> > > --
> > > Regards,
> > >
> > > Atri
> > > Apache Concerted
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: What should we do of branch_8x? [ In reply to ]
+1 to remove all content and leave behind a README in 8.x and 7.x, and
it sounds like adding the .asf..yaml file could even prevent further
commits?

I hope there weren't any consequences of having a few unintended
commits in the 7x branch. Makes me feel it would be OK to handle this
cleanup asynchronously to the 9.0 release.

On Tue, Nov 23, 2021 at 10:14 AM Uwe Schindler <uwe@thetaphi.de> wrote:
>
> Hi,
>
> I checked a bit: branch_7x is also still alive and has some accidental commits in it. So maybe we should do the same there.
>
> In general if we change this, don't forget to change github workflows: https://github.com/apache/lucene-solr/blob/master/.github/workflows/ant.yml
>
> Side note: I am missing the .asf.yaml file in the master branch of old repo. Where is this information stored? This file was there also to protect branches from writing (at least in github): https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-BranchProtection
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Adrien Grand <jpountz@gmail.com>
> > Sent: Tuesday, November 23, 2021 2:02 PM
> > To: Lucene Dev <dev@lucene.apache.org>
> > Subject: Re: What should we do of branch_8x?
> >
> > It looks like there is now general agreement on removing branch_8x?
> >
> > I wonder if we should actually remove it, which is prone to
> > re-creating the branch by mistake, vs. replacing the content of the
> > repository with a README that says that this branch is no longer under
> > development like we did for the `master` branch.
> >
> > On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan.asf@cominvent.com>
> > wrote:
> > >
> > > +1 to remove / lock branch_8x in the lucene-solr repo, i.e. there will not be an
> > 8.12 release by Lucene PMC.
> > >
> > > Whether Solr needs to release an 8.12 from own repos or not can be
> > discussed in dev@solr if/when needed. So far there is only loose talk, and I
> > think Solr PMC's energy should be devoted to the Solr 9.0 release.
> > >
> > > Jan
> > >
> > > > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <atri@apache.org>:
> > > >
> > > > +1, agree with Uwe.
> > > >
> > > > On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
> > > > <ichattopadhyaya@gmail.com> wrote:
> > > >>
> > > >> +1 to Uwe's suggestion
> > > >>
> > > >> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com>
> > wrote:
> > > >>>
> > > >>> +1 to uwe's suggestion
> > > >>>
> > > >>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.paul@gmail.com>
> > 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 <uwe@thetaphi.de>
> > 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.paul@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 <jpountz@gmail.com>
> > 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
> > <uwe@thetaphi.de> 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: uwe@thetaphi.de
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> From: Gus Heck <gus.heck@gmail.com>
> > > >>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
> > > >>>>>>>> To: dev <dev@lucene.apache.org>
> > > >>>>>>>> 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
> > <rcmuir@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
> > > >>>>>>>> <ichattopadhyaya@gmail.com> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com>
> > 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
> > > >>>>>>>>>> <ichattopadhyaya@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 Solr repo's "lucene-solr/branch_8x"
> > branch.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir
> > <rcmuir@gmail.com> 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
> > > >>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> > <rcmuir@gmail.com> 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
> > > >>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> > <uwe@thetaphi.de> 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 <rcmuir@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
> > > >>>>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> > <rcmuir@gmail.com> 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
> > <jpountz@gmail.com> 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-
> > unsubscribe@lucene.apache.org
> > > >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
> > help@lucene.apache.org
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> ________________________________
> > > >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-
> > unsubscribe@lucene.apache.org
> > > >>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
> > help@lucene.apache.org
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>> Uwe Schindler
> > > >>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen
> > > >>>>>>>>>>>>>>>> https://www.thetaphi.de
> > > >>>>>>>>
> > > >>>>>>>> ---------------------------------------------------------------------
> > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>>
> > > >>>>>>>> http://www.needhamsoftware.com (work)
> > > >>>>>>>>
> > > >>>>>>>> http://www.the111shift.com (play)
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> Adrien
> > > >>>>>
> > > >>>>> --
> > > >>>>> Uwe Schindler
> > > >>>>> Achterdiek 19, 28357 Bremen
> > > >>>>> https://www.thetaphi.de
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> http://www.needhamsoftware.com (work)
> > > >>> http://www.the111shift.com (play)
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Atri
> > > > Apache Concerted
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> >
> > --
> > Adrien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: What should we do of branch_8x? [ In reply to ]
> Makes me feel it would be OK to handle this cleanup asynchronously to the
9.0 release.
+1. It is unreasonable to hold up the 9.0 release for this.

On Tue, Nov 23, 2021 at 9:03 PM Michael Sokolov <msokolov@gmail.com> wrote:

> +1 to remove all content and leave behind a README in 8.x and 7.x, and
> it sounds like adding the .asf..yaml file could even prevent further
> commits?
>
> I hope there weren't any consequences of having a few unintended
> commits in the 7x branch. Makes me feel it would be OK to handle this
> cleanup asynchronously to the 9.0 release.
>
> On Tue, Nov 23, 2021 at 10:14 AM Uwe Schindler <uwe@thetaphi.de> wrote:
> >
> > Hi,
> >
> > I checked a bit: branch_7x is also still alive and has some accidental
> commits in it. So maybe we should do the same there.
> >
> > In general if we change this, don't forget to change github workflows:
> https://github.com/apache/lucene-solr/blob/master/.github/workflows/ant.yml
> >
> > Side note: I am missing the .asf.yaml file in the master branch of old
> repo. Where is this information stored? This file was there also to protect
> branches from writing (at least in github):
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-BranchProtection
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Adrien Grand <jpountz@gmail.com>
> > > Sent: Tuesday, November 23, 2021 2:02 PM
> > > To: Lucene Dev <dev@lucene.apache.org>
> > > Subject: Re: What should we do of branch_8x?
> > >
> > > It looks like there is now general agreement on removing branch_8x?
> > >
> > > I wonder if we should actually remove it, which is prone to
> > > re-creating the branch by mistake, vs. replacing the content of the
> > > repository with a README that says that this branch is no longer under
> > > development like we did for the `master` branch.
> > >
> > > On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan.asf@cominvent.com>
> > > wrote:
> > > >
> > > > +1 to remove / lock branch_8x in the lucene-solr repo, i.e. there
> will not be an
> > > 8.12 release by Lucene PMC.
> > > >
> > > > Whether Solr needs to release an 8.12 from own repos or not can be
> > > discussed in dev@solr if/when needed. So far there is only loose
> talk, and I
> > > think Solr PMC's energy should be devoted to the Solr 9.0 release.
> > > >
> > > > Jan
> > > >
> > > > > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <atri@apache.org>:
> > > > >
> > > > > +1, agree with Uwe.
> > > > >
> > > > > On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
> > > > > <ichattopadhyaya@gmail.com> wrote:
> > > > >>
> > > > >> +1 to Uwe's suggestion
> > > > >>
> > > > >> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com>
> > > wrote:
> > > > >>>
> > > > >>> +1 to uwe's suggestion
> > > > >>>
> > > > >>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <
> noble.paul@gmail.com>
> > > 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 <uwe@thetaphi.de>
> > > 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.paul@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 <jpountz@gmail.com
> >
> > > 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
> > > <uwe@thetaphi.de> 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: uwe@thetaphi.de
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> From: Gus Heck <gus.heck@gmail.com>
> > > > >>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
> > > > >>>>>>>> To: dev <dev@lucene.apache.org>
> > > > >>>>>>>> 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
> > > <rcmuir@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
> > > > >>>>>>>> <ichattopadhyaya@gmail.com> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <
> rcmuir@gmail.com>
> > > 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
> > > > >>>>>>>>>> <ichattopadhyaya@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 Solr repo's
> "lucene-solr/branch_8x"
> > > branch.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir
> > > <rcmuir@gmail.com> 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
> > > > >>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> > > <rcmuir@gmail.com> 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
> > > > >>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> > > <uwe@thetaphi.de> 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 <rcmuir@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
> > > > >>>>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> > > <rcmuir@gmail.com> 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
> > > <jpountz@gmail.com> 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-
> > > unsubscribe@lucene.apache.org
> > > > >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
> > > help@lucene.apache.org
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> ________________________________
> > > > >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-
> > > unsubscribe@lucene.apache.org
> > > > >>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
> > > help@lucene.apache.org
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>> Uwe Schindler
> > > > >>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen
> > > > >>>>>>>>>>>>>>>> https://www.thetaphi.de
> > > > >>>>>>>>
> > > > >>>>>>>>
> ---------------------------------------------------------------------
> > > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> --
> > > > >>>>>>>>
> > > > >>>>>>>> http://www.needhamsoftware.com (work)
> > > > >>>>>>>>
> > > > >>>>>>>> http://www.the111shift.com (play)
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> --
> > > > >>>>>>> Adrien
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>> Uwe Schindler
> > > > >>>>> Achterdiek 19, 28357 Bremen
> > > > >>>>> https://www.thetaphi.de
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>> http://www.needhamsoftware.com (work)
> > > > >>> http://www.the111shift.com (play)
> > > > >
> > > > > --
> > > > > Regards,
> > > > >
> > > > > Atri
> > > > > Apache Concerted
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > >
> > >
> > >
> > > --
> > > Adrien
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: What should we do of branch_8x? [ In reply to ]
I opened a PR that adds a commit that wipes the content of branch_8x on the
lucene-solr repository, including the GitHub workflow, and adds a simple
README that explains that 8.11 was the last minor release of the 8.x
series. I didn't add anything about the fact that there might be (or not)
more Solr-specific 8.x releases, since it made the message too complicated.
We can still edit this README if/when we do something about it.

https://github.com/apache/lucene-solr/pull/2616

On Tue, Nov 23, 2021 at 5:17 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> > Makes me feel it would be OK to handle this cleanup asynchronously to
> the 9.0 release.
> +1. It is unreasonable to hold up the 9.0 release for this.
>
> On Tue, Nov 23, 2021 at 9:03 PM Michael Sokolov <msokolov@gmail.com>
> wrote:
>
>> +1 to remove all content and leave behind a README in 8.x and 7.x, and
>> it sounds like adding the .asf..yaml file could even prevent further
>> commits?
>>
>> I hope there weren't any consequences of having a few unintended
>> commits in the 7x branch. Makes me feel it would be OK to handle this
>> cleanup asynchronously to the 9.0 release.
>>
>> On Tue, Nov 23, 2021 at 10:14 AM Uwe Schindler <uwe@thetaphi.de> wrote:
>> >
>> > Hi,
>> >
>> > I checked a bit: branch_7x is also still alive and has some accidental
>> commits in it. So maybe we should do the same there.
>> >
>> > In general if we change this, don't forget to change github workflows:
>> https://github.com/apache/lucene-solr/blob/master/.github/workflows/ant.yml
>> >
>> > Side note: I am missing the .asf.yaml file in the master branch of old
>> repo. Where is this information stored? This file was there also to protect
>> branches from writing (at least in github):
>> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-BranchProtection
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > https://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> > > -----Original Message-----
>> > > From: Adrien Grand <jpountz@gmail.com>
>> > > Sent: Tuesday, November 23, 2021 2:02 PM
>> > > To: Lucene Dev <dev@lucene.apache.org>
>> > > Subject: Re: What should we do of branch_8x?
>> > >
>> > > It looks like there is now general agreement on removing branch_8x?
>> > >
>> > > I wonder if we should actually remove it, which is prone to
>> > > re-creating the branch by mistake, vs. replacing the content of the
>> > > repository with a README that says that this branch is no longer under
>> > > development like we did for the `master` branch.
>> > >
>> > > On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan.asf@cominvent.com>
>> > > wrote:
>> > > >
>> > > > +1 to remove / lock branch_8x in the lucene-solr repo, i.e. there
>> will not be an
>> > > 8.12 release by Lucene PMC.
>> > > >
>> > > > Whether Solr needs to release an 8.12 from own repos or not can be
>> > > discussed in dev@solr if/when needed. So far there is only loose
>> talk, and I
>> > > think Solr PMC's energy should be devoted to the Solr 9.0 release.
>> > > >
>> > > > Jan
>> > > >
>> > > > > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <atri@apache.org>:
>> > > > >
>> > > > > +1, agree with Uwe.
>> > > > >
>> > > > > On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
>> > > > > <ichattopadhyaya@gmail.com> wrote:
>> > > > >>
>> > > > >> +1 to Uwe's suggestion
>> > > > >>
>> > > > >> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com>
>> > > wrote:
>> > > > >>>
>> > > > >>> +1 to uwe's suggestion
>> > > > >>>
>> > > > >>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <
>> noble.paul@gmail.com>
>> > > 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 <uwe@thetaphi.de>
>> > > 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.paul@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 <
>> jpountz@gmail.com>
>> > > 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
>> > > <uwe@thetaphi.de> 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: uwe@thetaphi.de
>> > > > >>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>> From: Gus Heck <gus.heck@gmail.com>
>> > > > >>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
>> > > > >>>>>>>> To: dev <dev@lucene.apache.org>
>> > > > >>>>>>>> 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
>> > > <rcmuir@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
>> > > > >>>>>>>> <ichattopadhyaya@gmail.com> wrote:
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <
>> rcmuir@gmail.com>
>> > > 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
>> > > > >>>>>>>>>> <ichattopadhyaya@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 Solr repo's
>> "lucene-solr/branch_8x"
>> > > branch.
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir
>> > > <rcmuir@gmail.com> 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
>> > > > >>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
>> > > <rcmuir@gmail.com> 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
>> > > > >>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
>> > > <uwe@thetaphi.de> 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 <rcmuir@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
>> > > > >>>>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
>> > > <rcmuir@gmail.com> 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
>> > > <jpountz@gmail.com> 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-
>> > > unsubscribe@lucene.apache.org
>> > > > >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
>> > > help@lucene.apache.org
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> ________________________________
>> > > > >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-
>> > > unsubscribe@lucene.apache.org
>> > > > >>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
>> > > help@lucene.apache.org
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> --
>> > > > >>>>>>>>>>>>>>>> Uwe Schindler
>> > > > >>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen
>> > > > >>>>>>>>>>>>>>>> https://www.thetaphi.de
>> > > > >>>>>>>>
>> > > > >>>>>>>>
>> ---------------------------------------------------------------------
>> > > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > >>>>>>>> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> > > > >>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>> --
>> > > > >>>>>>>>
>> > > > >>>>>>>> http://www.needhamsoftware.com (work)
>> > > > >>>>>>>>
>> > > > >>>>>>>> http://www.the111shift.com (play)
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>> --
>> > > > >>>>>>> Adrien
>> > > > >>>>>
>> > > > >>>>> --
>> > > > >>>>> Uwe Schindler
>> > > > >>>>> Achterdiek 19, 28357 Bremen
>> > > > >>>>> https://www.thetaphi.de
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> --
>> > > > >>> http://www.needhamsoftware.com (work)
>> > > > >>> http://www.the111shift.com (play)
>> > > > >
>> > > > > --
>> > > > > Regards,
>> > > > >
>> > > > > Atri
>> > > > > Apache Concerted
>> > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > > >
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > >
>> > >
>> > > --
>> > > Adrien
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

--
Adrien
Re: What should we do of branch_8x? [ In reply to ]
I went ahead and merged the above PR, which wiped out the comment of
branch_8x: https://github.com/apache/lucene-solr/tree/branch_8x.

I also removed the 8.x builds on Apache Jenkins (which were only disabled
until now).

On Tue, Nov 23, 2021 at 7:52 PM Adrien Grand <jpountz@gmail.com> wrote:

> I opened a PR that adds a commit that wipes the content of branch_8x on
> the lucene-solr repository, including the GitHub workflow, and adds a
> simple README that explains that 8.11 was the last minor release of the 8.x
> series. I didn't add anything about the fact that there might be (or not)
> more Solr-specific 8.x releases, since it made the message too complicated.
> We can still edit this README if/when we do something about it.
>
> https://github.com/apache/lucene-solr/pull/2616
>
> On Tue, Nov 23, 2021 at 5:17 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> > Makes me feel it would be OK to handle this cleanup asynchronously to
>> the 9.0 release.
>> +1. It is unreasonable to hold up the 9.0 release for this.
>>
>> On Tue, Nov 23, 2021 at 9:03 PM Michael Sokolov <msokolov@gmail.com>
>> wrote:
>>
>>> +1 to remove all content and leave behind a README in 8.x and 7.x, and
>>> it sounds like adding the .asf..yaml file could even prevent further
>>> commits?
>>>
>>> I hope there weren't any consequences of having a few unintended
>>> commits in the 7x branch. Makes me feel it would be OK to handle this
>>> cleanup asynchronously to the 9.0 release.
>>>
>>> On Tue, Nov 23, 2021 at 10:14 AM Uwe Schindler <uwe@thetaphi.de> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I checked a bit: branch_7x is also still alive and has some accidental
>>> commits in it. So maybe we should do the same there.
>>> >
>>> > In general if we change this, don't forget to change github workflows:
>>> https://github.com/apache/lucene-solr/blob/master/.github/workflows/ant.yml
>>> >
>>> > Side note: I am missing the .asf.yaml file in the master branch of old
>>> repo. Where is this information stored? This file was there also to protect
>>> branches from writing (at least in github):
>>> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-BranchProtection
>>> >
>>> > Uwe
>>> >
>>> > -----
>>> > Uwe Schindler
>>> > Achterdiek 19, D-28357 Bremen
>>> > https://www.thetaphi.de
>>> > eMail: uwe@thetaphi.de
>>> >
>>> > > -----Original Message-----
>>> > > From: Adrien Grand <jpountz@gmail.com>
>>> > > Sent: Tuesday, November 23, 2021 2:02 PM
>>> > > To: Lucene Dev <dev@lucene.apache.org>
>>> > > Subject: Re: What should we do of branch_8x?
>>> > >
>>> > > It looks like there is now general agreement on removing branch_8x?
>>> > >
>>> > > I wonder if we should actually remove it, which is prone to
>>> > > re-creating the branch by mistake, vs. replacing the content of the
>>> > > repository with a README that says that this branch is no longer
>>> under
>>> > > development like we did for the `master` branch.
>>> > >
>>> > > On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan.asf@cominvent.com>
>>> > > wrote:
>>> > > >
>>> > > > +1 to remove / lock branch_8x in the lucene-solr repo, i.e. there
>>> will not be an
>>> > > 8.12 release by Lucene PMC.
>>> > > >
>>> > > > Whether Solr needs to release an 8.12 from own repos or not can be
>>> > > discussed in dev@solr if/when needed. So far there is only loose
>>> talk, and I
>>> > > think Solr PMC's energy should be devoted to the Solr 9.0 release.
>>> > > >
>>> > > > Jan
>>> > > >
>>> > > > > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <atri@apache.org>:
>>> > > > >
>>> > > > > +1, agree with Uwe.
>>> > > > >
>>> > > > > On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
>>> > > > > <ichattopadhyaya@gmail.com> wrote:
>>> > > > >>
>>> > > > >> +1 to Uwe's suggestion
>>> > > > >>
>>> > > > >> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com>
>>> > > wrote:
>>> > > > >>>
>>> > > > >>> +1 to uwe's suggestion
>>> > > > >>>
>>> > > > >>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <
>>> noble.paul@gmail.com>
>>> > > 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 <uwe@thetaphi.de>
>>> > > 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.paul@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 <
>>> jpountz@gmail.com>
>>> > > 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
>>> > > <uwe@thetaphi.de> 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: uwe@thetaphi.de
>>> > > > >>>>>>>>
>>> > > > >>>>>>>>
>>> > > > >>>>>>>>
>>> > > > >>>>>>>> From: Gus Heck <gus.heck@gmail.com>
>>> > > > >>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
>>> > > > >>>>>>>> To: dev <dev@lucene.apache.org>
>>> > > > >>>>>>>> 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
>>> > > <rcmuir@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
>>> > > > >>>>>>>> <ichattopadhyaya@gmail.com> wrote:
>>> > > > >>>>>>>>>
>>> > > > >>>>>>>>>
>>> > > > >>>>>>>>>
>>> > > > >>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <
>>> rcmuir@gmail.com>
>>> > > 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
>>> > > > >>>>>>>>>> <ichattopadhyaya@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 Solr repo's
>>> "lucene-solr/branch_8x"
>>> > > branch.
>>> > > > >>>>>>>>>>>
>>> > > > >>>>>>>>>>>
>>> > > > >>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir
>>> > > <rcmuir@gmail.com> 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
>>> > > > >>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
>>> > > <rcmuir@gmail.com> 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
>>> > > > >>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
>>> > > <uwe@thetaphi.de> 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 <rcmuir@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
>>> > > > >>>>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
>>> > > <rcmuir@gmail.com> 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
>>> > > <jpountz@gmail.com> 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-
>>> > > unsubscribe@lucene.apache.org
>>> > > > >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
>>> > > help@lucene.apache.org
>>> > > > >>>>>>>>>>>>>>>>>>>
>>> > > > >>>>>>>>>>>>>>>>> ________________________________
>>> > > > >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-
>>> > > unsubscribe@lucene.apache.org
>>> > > > >>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
>>> > > help@lucene.apache.org
>>> > > > >>>>>>>>>>>>>>>>>
>>> > > > >>>>>>>>>>>>>>>> --
>>> > > > >>>>>>>>>>>>>>>> Uwe Schindler
>>> > > > >>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen
>>> > > > >>>>>>>>>>>>>>>> https://www.thetaphi.de
>>> > > > >>>>>>>>
>>> > > > >>>>>>>>
>>> ---------------------------------------------------------------------
>>> > > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> > > > >>>>>>>> For additional commands, e-mail:
>>> dev-help@lucene.apache.org
>>> > > > >>>>>>>>
>>> > > > >>>>>>>>
>>> > > > >>>>>>>>
>>> > > > >>>>>>>> --
>>> > > > >>>>>>>>
>>> > > > >>>>>>>> http://www.needhamsoftware.com (work)
>>> > > > >>>>>>>>
>>> > > > >>>>>>>> http://www.the111shift.com (play)
>>> > > > >>>>>>>
>>> > > > >>>>>>>
>>> > > > >>>>>>>
>>> > > > >>>>>>> --
>>> > > > >>>>>>> Adrien
>>> > > > >>>>>
>>> > > > >>>>> --
>>> > > > >>>>> Uwe Schindler
>>> > > > >>>>> Achterdiek 19, 28357 Bremen
>>> > > > >>>>> https://www.thetaphi.de
>>> > > > >>>
>>> > > > >>>
>>> > > > >>>
>>> > > > >>> --
>>> > > > >>> http://www.needhamsoftware.com (work)
>>> > > > >>> http://www.the111shift.com (play)
>>> > > > >
>>> > > > > --
>>> > > > > Regards,
>>> > > > >
>>> > > > > Atri
>>> > > > > Apache Concerted
>>> > > > >
>>> > > > >
>>> ---------------------------------------------------------------------
>>> > > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> > > > > For additional commands, e-mail: dev-help@lucene.apache.org
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> ---------------------------------------------------------------------
>>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>>> > > >
>>> > >
>>> > >
>>> > > --
>>> > > Adrien
>>> > >
>>> > > ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> > > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>
> --
> Adrien
>


--
Adrien
RE: What should we do of branch_8x? [ In reply to ]
Policeman Jenkins was also disabled. But I will remove those now.



-----

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: uwe@thetaphi.de



From: Adrien Grand <jpountz@gmail.com>
Sent: Wednesday, November 24, 2021 5:00 PM
To: Lucene Dev <dev@lucene.apache.org>
Subject: Re: What should we do of branch_8x?



I went ahead and merged the above PR, which wiped out the comment of branch_8x: https://github.com/apache/lucene-solr/tree/branch_8x.



I also removed the 8.x builds on Apache Jenkins (which were only disabled until now).



On Tue, Nov 23, 2021 at 7:52 PM Adrien Grand <jpountz@gmail.com <mailto:jpountz@gmail.com> > wrote:

I opened a PR that adds a commit that wipes the content of branch_8x on the lucene-solr repository, including the GitHub workflow, and adds a simple README that explains that 8.11 was the last minor release of the 8.x series. I didn't add anything about the fact that there might be (or not) more Solr-specific 8.x releases, since it made the message too complicated. We can still edit this README if/when we do something about it.



https://github.com/apache/lucene-solr/pull/2616



On Tue, Nov 23, 2021 at 5:17 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com> > wrote:

> Makes me feel it would be OK to handle this cleanup asynchronously to the 9.0 release.

<https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif>

+1. It is unreasonable to hold up the 9.0 release for this.



On Tue, Nov 23, 2021 at 9:03 PM Michael Sokolov <msokolov@gmail.com <mailto:msokolov@gmail.com> > wrote:

+1 to remove all content and leave behind a README in 8.x and 7.x, and
it sounds like adding the .asf..yaml file could even prevent further
commits?

I hope there weren't any consequences of having a few unintended
commits in the 7x branch. Makes me feel it would be OK to handle this
cleanup asynchronously to the 9.0 release.

On Tue, Nov 23, 2021 at 10:14 AM Uwe Schindler <uwe@thetaphi.de <mailto:uwe@thetaphi.de> > wrote:
>
> Hi,
>
> I checked a bit: branch_7x is also still alive and has some accidental commits in it. So maybe we should do the same there.
>
> In general if we change this, don't forget to change github workflows: https://github.com/apache/lucene-solr/blob/master/.github/workflows/ant.yml
>
> Side note: I am missing the .asf.yaml file in the master branch of old repo. Where is this information stored? This file was there also to protect branches from writing (at least in github): https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-BranchProtection
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
>
> > -----Original Message-----
> > From: Adrien Grand <jpountz@gmail.com <mailto:jpountz@gmail.com> >
> > Sent: Tuesday, November 23, 2021 2:02 PM
> > To: Lucene Dev <dev@lucene.apache.org <mailto:dev@lucene.apache.org> >
> > Subject: Re: What should we do of branch_8x?
> >
> > It looks like there is now general agreement on removing branch_8x?
> >
> > I wonder if we should actually remove it, which is prone to
> > re-creating the branch by mistake, vs. replacing the content of the
> > repository with a README that says that this branch is no longer under
> > development like we did for the `master` branch.
> >
> > On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan.asf@cominvent.com <mailto:jan.asf@cominvent.com> >
> > wrote:
> > >
> > > +1 to remove / lock branch_8x in the lucene-solr repo, i.e. there will not be an
> > 8.12 release by Lucene PMC.
> > >
> > > Whether Solr needs to release an 8.12 from own repos or not can be
> > discussed in dev@solr if/when needed. So far there is only loose talk, and I
> > think Solr PMC's energy should be devoted to the Solr 9.0 release.
> > >
> > > Jan
> > >
> > > > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <atri@apache.org <mailto:atri@apache.org> >:
> > > >
> > > > +1, agree with Uwe.
> > > >
> > > > On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
> > > > <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com> > wrote:
> > > >>
> > > >> +1 to Uwe's suggestion
> > > >>
> > > >> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.heck@gmail.com <mailto:gus.heck@gmail.com> >
> > wrote:
> > > >>>
> > > >>> +1 to uwe's suggestion
> > > >>>
> > > >>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.paul@gmail.com <mailto:noble.paul@gmail.com> >
> > 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 <uwe@thetaphi.de <mailto:uwe@thetaphi.de> >
> > 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.paul@gmail.com <mailto:noble.paul@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 <jpountz@gmail.com <mailto:jpountz@gmail.com> >
> > 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
> > <uwe@thetaphi.de <mailto:uwe@thetaphi.de> > 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: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> From: Gus Heck <gus.heck@gmail.com <mailto:gus.heck@gmail.com> >
> > > >>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM
> > > >>>>>>>> To: dev <dev@lucene.apache.org <mailto:dev@lucene.apache.org> >
> > > >>>>>>>> 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
> > <rcmuir@gmail.com <mailto:rcmuir@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
> > > >>>>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com> > wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcmuir@gmail.com <mailto:rcmuir@gmail.com> >
> > 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
> > > >>>>>>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@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 Solr repo's "lucene-solr/branch_8x"
> > branch.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir
> > <rcmuir@gmail.com <mailto:rcmuir@gmail.com> > 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
> > > >>>>>>>>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com> > 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,
> > <rcmuir@gmail.com <mailto:rcmuir@gmail.com> > 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
> > > >>>>>>>>>>>>>> <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com> > 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,
> > <uwe@thetaphi.de <mailto:uwe@thetaphi.de> > 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 <rcmuir@gmail.com <mailto:rcmuir@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
> > > >>>>>>>>>>>>>>>>> <ichattopadhyaya@gmail.com> 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,
> > <rcmuir@gmail.com <mailto:rcmuir@gmail.com> > 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
> > <jpountz@gmail.com <mailto:jpountz@gmail.com> > 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-
> > unsubscribe@lucene.apache.org <mailto:unsubscribe@lucene.apache.org>
> > > >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
> > help@lucene.apache.org <mailto:help@lucene.apache.org>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> ________________________________
> > > >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-
> > unsubscribe@lucene.apache.org <mailto:unsubscribe@lucene.apache.org>
> > > >>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-
> > help@lucene.apache.org <mailto:help@lucene.apache.org>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>> Uwe Schindler
> > > >>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen
> > > >>>>>>>>>>>>>>>> https://www.thetaphi.de
> > > >>>>>>>>
> > > >>>>>>>> ---------------------------------------------------------------------
> > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> > > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>>
> > > >>>>>>>> http://www.needhamsoftware.com (work)
> > > >>>>>>>>
> > > >>>>>>>> http://www.the111shift.com (play)
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> Adrien
> > > >>>>>
> > > >>>>> --
> > > >>>>> Uwe Schindler
> > > >>>>> Achterdiek 19, 28357 Bremen
> > > >>>>> https://www.thetaphi.de
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> http://www.needhamsoftware.com (work)
> > > >>> http://www.the111shift.com (play)
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Atri
> > > > Apache Concerted
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> > > > For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> > > For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> > >
> >
> >
> > --
> > Adrien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> > For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>






--

Adrien






--

Adrien

1 2  View All