+1 to Uwe's suggestion On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <[email protected]> wrote:
> +1 to uwe's suggestion > > On Sun, Nov 21, 2021 at 10:42 PM Noble Paul <[email protected]> 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 <[email protected]> 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 < >>> [email protected]>: >>>> >>>> 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 <[email protected]> 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 <[email protected]> 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: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> *From:* Gus Heck <[email protected]> >>>>>> *Sent:* Sunday, November 21, 2021 5:05 PM >>>>>> *To:* dev <[email protected]> >>>>>> *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 <[email protected]> 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 >>>>>> <[email protected]> wrote: >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, <[email protected]> >>>>>> 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 >>>>>> >> <[email protected]> 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 <[email protected]> >>>>>> 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 >>>>>> >> >> <[email protected]> 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, <[email protected]> >>>>>> 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 >>>>>> >> >> >> <[email protected]> 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, < >>>>>> [email protected]> 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 < >>>>>> [email protected]>: >>>>>> >> >> >> >>> >>>>>> >> >> >> >>> 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 >>>>>> >> >> >> >>> <[email protected]> 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, < >>>>>> [email protected]> 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 < >>>>>> [email protected]> 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: >>>>>> [email protected] >>>>>> >> >> >> >>>>> For additional commands, e-mail: >>>>>> [email protected] >>>>>> >> >> >> >>>>> >>>>>> >> >> >> >>> ________________________________ >>>>>> >> >> >> >>> To unsubscribe, e-mail: >>>>>> [email protected] >>>>>> >> >> >> >>> For additional commands, e-mail: >>>>>> [email protected] >>>>>> >> >> >> >>> >>>>>> >> >> >> >> -- >>>>>> >> >> >> >> Uwe Schindler >>>>>> >> >> >> >> Achterdiek 19, 28357 Bremen >>>>>> >> >> >> >> https://www.thetaphi.de >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> 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) >
