V2 has existed since v6.5 and has been documented in ref guide evner since. In 7.0 release announcement we said:
The new v2 API, exposed at /api/ and also supported via SolrJ, is now the preferred API, but /solr/ continues to work. We have been showing v2 api commands in tabs for e.g. config api since 7.4. So users have been encouraged to switch for at least 3-4 years. Jan Høydahl > 16. jun. 2022 kl. 16:16 skrev Eric Pugh <ep...@opensourceconnections.com>: > > > I don’t have the link, but I think we agree that v2 *could* evolve, hence the > whole experimental thing. > > I worry that the efforts of maintaining three versions of the api will stall > us. Especially if the changes we want to make aren’t wholesale changes. > Now if we introduced a graphql based api, that might justify the v3 tag. > > My gut feeling is that no one uses v2 yet, so the end user impact is minimal. > > Maybe run a quick survey to decide that? > >> On Thu, Jun 16, 2022 at 5:41 AM Jan Høydahl <jan....@cominvent.com> wrote: >> HI, >> >> Thanks for having the guts to start such a journey! >> V2 has been around for several major releases and documented (it's in v6.6 >> guide https://solr.apache.org/guide/6_6/v2-api.html) long enough that we >> must assume a certain user base already. >> The "experimental" warning in RefGuide is not prominent between 6.6 and >> 8.11, looks like it was added in the 9.0 guide. >> Thus I'm not sure we should act as if the entire v2 design is up for change. >> >> So perhaps the next-gen, OpenApi style APIs should be v3 and then deprecate >> both v1 and v2 once the coverage is sufficient? I assume v3 could still >> stand on v2's sholders? >> Or if you plan to target a v2 rewrite for 10.0 only then I suppose it could >> be a rewrite of v2 since it will be in a major version, but then we need to >> know we can complete the work by then. >> >> Jan >> >>> 16. jun. 2022 kl. 13:03 skrev Jason Gerlowski <gerlowsk...@gmail.com>: >>> >>> Hi all, >>> >>> I've been working over the last few months to get our "v2" API into >>> shape to eventually replace (and allow us to sunset) v1. At a high >>> level the two biggest next-steps are to (1) make whatever changes we'd >>> like to the v2 endpoints while they're still "experimental", and then >>> (2) start using them across Solr (Admin UI, SolrJ, etc.) >>> >>> The big question in my mind is: what all should change in the v2 >>> endpoints as part of item #1 above. Do people like the current v2 >>> design enough to move forward as-is (or with some minor tweaking)? Or >>> is there interest in seeing a larger re-alignment around other design >>> principles (e.g. REST, OpenAPI, etc.) while v2 is still >>> "experimental"? >>> >>> My impression from past discussions is that there's interest in seeing >>> broader changes to v2 (see [1] and [2] below). I tend to agree and >>> I'm willing to head up that effort. But I wanted to double-check >>> first that there was consensus on the overall idea of "broader >>> changes" before I start filing JIRAs and working out specifics. >>> >>> Assuming consensus, my next step will be to write up the current v2 >>> endpoints and some proposed changes in a spreadsheet that we can >>> iterate on. (Feedback on specific APIs, changes, etc. definitely >>> welcome at that point once I get there.) >>> >>> Best, >>> >>> Jason >>> >>> [1] "Should v2 API be experimental" - >>> https://lists.apache.org/thread/t342hl7lvt5b4qmb5vrrh7tvmdjlbb22 >>> [2] "Solr 9.0 Release Blockers"" - >>> https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >>
