[jira] [Comment Edited] (SOLR-15734) Prepare v2 API for v1 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=17566901#comment-17566901 ] 

Jason Gerlowski edited comment on SOLR-15734 at 7/14/22 4:05 PM:
-----------------------------------------------------------------

{quote}link them to this one as a "fixed by" ... SOLR-12224 is an example{quote}

"Fixed by" might be a bit strong.  My main worry is scope creep I guess.  The goal of this ticket is to get v2 ready to replace v1; we don't need to add net-new v2 endpoints that are missing even from v1 to do that, strictly speaking.

Of course - I do want to see those missing endpoints get added.  But from a bookkeeping perspective they might not be totally "fixed by" this ticket.

But I agree with your larger point I think - that we will have to go through our API-related tickets at some point and see which ones are worth keeping open in a world where v1 is deprecated or gone entirely.


was (Author: gerlowskija):
{quote}link them to this one as a "fixed by" ... SOLR-12224 is an example{quote}

"Fixed by" might be a bit strong.  My main worry is scope creep I guess.  The goal of this ticket is to get v2 ready to replace v1; we don't need to add net-new v2 endpoints that are missing even from v1 to do that, strictly speaking.

Of course - I do want to see those missing endpoints get added.  But from a bookkeeping perspective they might not be totally "fixed by" this ticket.

> Prepare v2 API for v1 deprecation, eventual removal
> ---------------------------------------------------
>
>                 Key: SOLR-15734
>                 URL: https://issues.apache.org/jira/browse/SOLR-15734
>             Project: Solr
>          Issue Type: Improvement
>          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.10#820010)

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