(The comments below are in the context of +1 of getting this working out.) When we say "let users try", do we mean actual public with a release published on our website?
Because I can see the publishing of version 10, however it is tagged (alpha, whatever), completely confusing people about the upcoming 9 version and causing an adoption delay. Especially combined with cleanups that we already put in 9.0. Maybe we could release it to committers community first and dogfood it "internally"? And if the issue with naming it 'not 10.x' is one piece of code (package manager), maybe we can one-off patch that instead. Or hack the version to be something ridiculous like 42 (the answer to everything...) instead of something that is psychologically feasible. I recall this dual version confusion happening before in other communities and it really messed things up. Python is a recent example, but I seem to recall other similar events for products/communities that no longer exist (hopefully for other reasons). And yes, all the questions of forward-porting are there as well, if/once this succeeds. Regards, Alex. Regards, Alex. On Sun, 4 Oct 2020 at 11:34, Varun Thacker <va...@vthacker.in> wrote: > > Hi Ishan, > > Let's say Solr 10 ( or whatever name gets picked ) turns out stable enough in > the alpha phase - What would the next step be? > > Would we bring back all the changes to master? Do you have a sense into how > that would end up playing out? Could it be brought in chunks or would it have > to be wholesale ? > > Also do you know what features in the reference branch have been removed > because they were unstable ? Finding out the features/bug-fixes in master > that haven't made it to the reference branch would be easier to find out. > > On Sat, Oct 3, 2020 at 10:17 PM Ishan Chattopadhyaya > <ichattopadhy...@gmail.com> wrote: >> >> Erick, I'll answer your questions shortly. >> >> On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, >> <ichattopadhy...@gmail.com> wrote: >>> >>> Agree, Noble. Let's not worry about the naming too much. We can discuss >>> that later as well, or in a separate thread. >>> >>> On Sun, 4 Oct, 2020, 10:06 am Noble Paul, <noble.p...@gmail.com> wrote: >>>> >>>> +1 Ishan >>>> >>>> It's important that the branch gets some real world testing and >>>> feedback. At this point we cannot be 100% sure about the stability of >>>> that branch to port all the changes to master. >>>> >>>> Users don't care what is Solr 9/Solr 10 or even Mark's Solr or even a >>>> "Crazy Solr". As long as all the tests pass and they can do an upgrade >>>> of their existing cluster to that release,that IS Solr. I think we do >>>> not need to worry too much about it now. If/when we reach a point >>>> where we have a new stable release of Solr that is 100% compatible >>>> with our other branch, we can resume this discussion. >>>> >>>> As Ilan said, we may get real feedback from our users deploying it on >>>> production scale but non critical deployments. Our JUnit tests are not >>>> good enough to uncover stability issues. >>>> >>>> Let's focus on making all the tests pass and get this to the hands of our >>>> users. >>>> >>>> On Sun, Oct 4, 2020 at 8:01 AM Uwe Schindler <u...@thetaphi.de> wrote: >>>> > >>>> > Is the branch ready for Jenkins testing? >>>> > >>>> > If yes and "gradlew check" works, I really would like to set it up. >>>> > >>>> > Uwe >>>> > >>>> > Am October 3, 2020 7:42:22 PM UTC schrieb Ishan Chattopadhyaya >>>> > <ichattopadhy...@gmail.com>: >>>> >> >>>> >> Hi Devs, >>>> >> >>>> >> As you might be aware, the reference_impl branch has a lot of >>>> >> improvements that we want to see in Solr master. However, it is >>>> >> currently a large deviation from master and hence the stability and >>>> >> reliability (though improved in certain aspects) remains to be tested >>>> >> in real production environments before we gain confidence in bringing >>>> >> those changes to master. >>>> >> >>>> >> I propose that we do a one off preview release from that branch, say >>>> >> Solr 10 alpha (early access) or any other name that someone suggests, >>>> >> so that users could try it out and report regressions or improvements >>>> >> etc. >>>> >> >>>> >> I volunteer to be the RM and planning to start the process around 1 >>>> >> December-15 December timeframe. Until then, we can tighten the loose >>>> >> ends on the branch and plan for such a release. >>>> >> >>>> >> Is there any thoughts, concerns, questions? >>>> >> >>>> >> Regards, >>>> >> Ishan >>>> > >>>> > >>>> > -- >>>> > Uwe Schindler >>>> > Achterdiek 19, 28357 Bremen >>>> > https://www.thetaphi.de >>>> >>>> >>>> >>>> -- >>>> ----------------------------------------------------- >>>> Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
