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
