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
>
- 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
>