[
https://issues.apache.org/jira/browse/SOLR-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761388#comment-17761388
]
ASF subversion and git services commented on SOLR-15734:
--------------------------------------------------------
Commit 492e5a8a59d34cbf9f15507e2bd4f65b118ba986 in solr's branch
refs/heads/branch_9x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=492e5a8a59d ]
SOLR-15734: Add dev-docs on Solr APIs (#1876)
Solr's API situation generally has seen a lot of change in the last few
years. Some documentation on how Solr "does" APIs currently and how
users may write new APIs should go a long way towards making it easier
for developers to feel comfortable in this part of the code.
> 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
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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
