Sorry, I just don't understand the implications of what you are suggesting.
The code in question is lucene+solr combined, and the build system and packaging and everything only knows how to do that. So are you forking all the lucene code into the solr repo too? I don't really understand your need to have a branch_8x. we can nuke it, and you can do any of this from a branch_8_11 some other day, no? On Sun, Nov 21, 2021 at 7:57 AM Ishan Chattopadhyaya <ichattopadhy...@gmail.com> wrote: > > > I don't think the solr PMC should issue Lucene 8.12 either. > I never expressed any intention of doing so. Besides, is it even possible > (ASF policies wise)? > > This is a weekend, and I feel bad holding up the 9.0 release (since this is a > blocker). Solr PMC can decide later on Solr's releases, and hence I'm going > to copy this branch_8x over to Solr repo's "lucene-solr/branch_8x" branch. > > > On Sun, Nov 21, 2021 at 6:14 PM Robert Muir <rcm...@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 >> <ichattopadhy...@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, <rcm...@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 >> >> <ichattopadhy...@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, <u...@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 >> >> >> <rcm...@gmail.com>: >> >> >>> >> >> >>> I gave my technical justification: our backwards compatibility testing >> >> >>> doesnt work this way. 9.0 can't have guaranteed back compat with >> >> >>> versions coming in the future. This is lunacy. >> >> >>> >> >> >>> On Sun, Nov 21, 2021 at 6:30 AM Ishan Chattopadhyaya >> >> >>> <ichattopadhy...@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, <rcm...@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 <jpou...@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-unsubscr...@lucene.apache.org >> >> >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >>>>> >> >> >>> ________________________________ >> >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >>> >> >> >> -- >> >> >> Uwe Schindler >> >> >> Achterdiek 19, 28357 Bremen >> >> >> https://www.thetaphi.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
