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 >
