It looks like there is now general agreement on removing branch_8x? I wonder if we should actually remove it, which is prone to re-creating the branch by mistake, vs. replacing the content of the repository with a README that says that this branch is no longer under development like we did for the `master` branch.
On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan....@cominvent.com> wrote: > > +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 > -- Adrien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
