+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
