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)