Also, if someone has the time to take this up, can you please create a JIRA and mark is a usability blocker for 7.0 release ?
-Anshum On Mon, Jul 3, 2017 at 1:55 PM Anshum Gupta <ans...@anshumgupta.net> wrote: > +1 to not having v2. I don't have a personal preference between the > suggestions by Shawn, and Jan, so like David, either of them would be great. > > -Anshum > > > On Fri, Jun 16, 2017 at 6:59 AM Jan Høydahl <jan....@cominvent.com> wrote: > >> Hi, >> >> 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/? >> >> The answer may seem obvious to many of you and may have consensus in some >> looong JIRA discussion that I did not follow. >> >> But I have a sneaking feeling that we’ll still be at /v2/ 5 years from >> now and that we’ll use other mechanisms for >> making breaking changes in one or more of the APIs, rather than bumping >> the main entry point, which has a high cost. >> In this regard I believe perhaps Solr as an app is different from any >> publicly available SAAS out on the internet, >> and if someone needed to publish a Solr search to a bunch of unknown >> clients they would not expose Solr to those >> clients but rather their own proxy, and the whole /v2, /v3 thing would be >> controlled by their API layer above Solr. >> >> Feel free to shoot me down, but is localhost:8983/api/ a more honest >> naming for v2? >> * It looks much better >> * It is intuitive to everyone >> * It never gets outdated >> * We can still move to /api/v3 or anything else in the future if so be >> >> So if my gut feeling is wrong here, please tell me a likely event in, say >> Solr8 that would warrant a /v3 in parallel >> with /v2. If this is something that will happen once every 5 years and >> not once every major version, then perhaps >> other ways of versioning is more appropriate? (HTTP headers?, API paths >> /api/c/foo/backup2 ...)? >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
