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
