Jason Gerlowski created SOLR-15734:
--------------------------------------
Summary: Prepare v2 API for v2 deprecation, eventual removal
Key: SOLR-15734
URL: https://issues.apache.org/jira/browse/SOLR-15734
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: v2 API
Reporter: Jason Gerlowski
Solr's v2 API has seen noticable progress in the past 6 months both in the code
and docs. With 9.0 looming there's been some interest in getting the v2 API in
good enough shape to finally deprecate Solr's v1 API.
Before this can happen though, there's still a good chunk of work needed to
bring the v2 APIs up to parity with v1: both in terms of coverage and
stability/reliability. This ticket aims to map out those remaining pieces to
better track our progress and eventually make v1 deprecation and removal
possible. (A request for this sortof a roadmap came up in the recent "Solr 9.0
release blockers" dev@ thread.)
There's likely to be some debate on what's really needed to get the v2 APIs
ready for prime time, and that's totally fine. As a seed for this discussion
I'm populating this epic with the sub-tasks that seem required to me. For the
most part these fall into a few high-level categories:
* server-side parity: the v2 API should expose the same set of functionality as
v1, both in terms of endpoints and individual parameters
* client (SolrJ) parity: SolrJ request objects should be able to send V2
requests across the board (and perhaps do so by default). Various routing and
other optimizations built into SolrClient implementations should apply equally
to V1 and V2 requests.
* docs/ref-guide parity: Solr documentation should be updated to use the v2 API
where-ever possible.
* stability, trust, and dogfooding: It's difficult to recommend v2 to users
when we aren't using it ourselves: Solr's tests should randomize between v1 and
v2 API calls, v2 should be used by Solr-owned clients (e.g. Admin UI, bin/solr)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
