On 6/16/2017 7:59 AM, Jan Høydahl wrote: > Now that we’re getting used to thinking localhost:8983/v2/ as the new api > entry point, just one silly question: > > Will we ever move beyond /v2/ to /v3/?
TL;DR: You sure you want to open this can of worms? This is one of my primary fears with putting a version number in the URL path. I have no opposition to a new API, I just feel that giving it a specific version number has some disadvantages. The biggest one is that I can foresee is that in a few years people will be asking "Why haven't you created a version 3 yet?" If it remains /v2 for a long time, some users might begin to think our API has gotten old and stale, instead of thinking that we did a good job on the v2 design. A change to the URL path does make our jobs as developers easier, especially in handling access to the old API, but I think that we should decide what makes the most sense and start migrating to it, without a version number. Personally, I would rather keep the primary path as /solr, possibly adding a component -- /solr/api is a possibility in place of /v2. It's relatively short and I don't think it would get perceived as stale. The following roadmap is appealing to me, and I think that people writing user and library code would very much appreciate how easy it would be to deal with the last step: *) In 7.x, deprecate old API. *) In 7.x, use /solr/api to access new API. *) In 8.0, eliminate old API and make the "/api" path component optional. *) In 9.0, remove the "/api" path component. If the new API is designed correctly, I think we can make major path changes like this unnecessary in the future, but if we really think that more major API changes are needed, we can maintain "/solr/api" as a way to access the new API under development. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
