+1, agree with Uwe. On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya <ichattopadhy...@gmail.com> wrote: > > +1 to Uwe's suggestion > > On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.h...@gmail.com> wrote: >> >> +1 to uwe's suggestion >> >> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <noble.p...@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 <u...@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.p...@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 <jpou...@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 <u...@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: u...@thetaphi.de >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Gus Heck <gus.h...@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 <rcm...@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 >>>>>>> <ichattopadhy...@gmail.com> wrote: >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <rcm...@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 >>>>>>> >> <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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
