+1 to remove / lock branch_8x in the lucene-solr repo, i.e. there will not be an 8.12 release by Lucene PMC.
Whether Solr needs to release an 8.12 from own repos or not can be discussed in dev@solr if/when needed. So far there is only loose talk, and I think Solr PMC's energy should be devoted to the Solr 9.0 release. Jan > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <a...@apache.org>: > > +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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
