[
https://issues.apache.org/jira/browse/SOLR-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740234#comment-17740234
]
ASF subversion and git services commented on SOLR-15734:
--------------------------------------------------------
Commit 9efb3681a5a59640c8a900304a1a6a169e9d8f64 in solr's branch
refs/heads/main from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=9efb3681a5a ]
SOLR-15734: Add "Major Changes" note for 9.3 v2 API changes
The 9.3 release will see a lot of improvements to the v2 API. This
commit adds a note on the "Major Changes in Solr 9" ref-guide page to
summarize those for users.
> 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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
