On 10/3/2020 1:42 PM, Ishan Chattopadhyaya wrote:
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.
(Original message was on dev@lucene, so this will seem out of the blue.
I wrote most of this last year, just hadn't sent it yet! It's been
sitting in my drafts forever. Sending to dev@solr now.)
How to handle this seems to come down to the answers to a couple of
questions:
* Is this new code stable enough to work in the wild?
* Do we want to release 9.0 before we merge Mark's work to main, or after?
Can someone who was involved when 4.0-ALPHA and 4.0-BETA were released
tell me whether those releases actually did what was intended and made
4.0.0 a better release? If they did, then a special release for this
new implementation before merging to main would probably also be
helpful. If there was no real benefit gained, then maybe we're better
off just going ahead with the merge.
If the general feeling is that this new release is looking very solid,
then I think we should merge to main soon, probably just before
branch_9x is created. If we think it needs more work, then maybe we
should hold on merging until *after* branch_9x is created, so the new
implementation will release with 10.0 and there will be more time to
work on it.
My current impression, which I will admit is made with almost zero
actual information about the code or its stability, is that we should
plan on stabilizing the new implementation for the 9.0 release. There's
going to be pain no matter how we handle this, so diving in now seems
like a good idea.
A tangent: How robust is our testing? I know they take a long time to
run, but do we think there's enough being tested? There has been some
discussion in the past about benchmarks for Solr. Benchmarks would be
cool, but I'm more interested in making sure that our tests will catch
problems before they get out into the wild.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org