[jira] [Commented] (SOLR-15734) Prepare v2 API for v2 deprecation, eventual removal

["Jason Gerlowski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441158#comment-17441158 ] 

Jason Gerlowski commented on SOLR-15734:
----------------------------------------

One thing I wanted to clarify that I realized was unclear in a conversation I had offline with epugh: references to server or client "parity" in the description above aren't meant to imply that v2 must expose every last thing in v1.  Just that there shouldn't be any _unintentional_ gaps in what we expose.  IMO it's totally fine if we choose to leave some functionality or APIs behind as we move to v2 - as long as its intentional and not an accidental omission as many gaps are today.

> 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
>            Priority: Major
>              Labels: V2
>
> 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.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org