I just realized that this issue was deprioritized from being a blocker. I strongly believe that this should be done now (7.0) to avoid user confusion going forward. I added a simple patch there (SOLR-11183); can someone please take a look?
On Thu, Aug 3, 2017 at 6:30 AM, Noble Paul <noble.p...@gmail.com> wrote: > created a blocker ticket > https://issues.apache.org/jira/browse/SOLR-11183 > > On Thu, Aug 3, 2017 at 10:23 AM, Noble Paul <noble.p...@gmail.com> wrote: > > I shall open a ticket. let's resolve it there > > > > On Wed, Aug 2, 2017 at 5:30 AM, Jan Høydahl <jan....@cominvent.com> > wrote: > >> Thanks for following up, Anshum. I'm on holiday so not much online.. > >> > >> Can you create a blocker JIRA to formally force a decision and provide a > >> place to upload a patch? > >> > >> Jan > >> > >> Den 1. aug. 2017 kl. 20.32 skrev Anshum Gupta <ans...@anshumgupta.net>: > >> > >> Bumping this up. > >> > >> Last call in case we want to change the endpoint, which I think we > should! > >> > >> Anshum > >> > >> On Mon, Jul 3, 2017 at 11:52 PM Noble Paul <noble.p...@gmail.com> > wrote: > >>> > >>> I meant /api in addition to /v2 > >>> > >>> On Jul 4, 2017 16:17, "Noble Paul" <noble.p...@gmail.com> wrote: > >>>> > >>>> /api is ok. It takes a non trivial amount of time to make this > change. I > >>>> would not want to hold up the release for this. We can easily add > support > >>>> for /api in addition to /api in the next release > >>>> > >>>> > >>>> On Jul 4, 2017 08:35, "Jan Høydahl" <jan....@cominvent.com> wrote: > >>>>> > >>>>> I’ll let this email thread run a little bit longer to gather > different > >>>>> views. > >>>>> Then in a few days we can try to discover a consensus and create a > JIRA. > >>>>> > >>>>> I think that the effort gone into moving Solr to root context allows > us > >>>>> great flexibility, whatever naming we want. > >>>>> As I said, I don’t think an app like Solr needs to keep older API > >>>>> versions alive for more than one major version, like a public web > service > >>>>> API would need. > >>>>> > >>>>> In 7.x we’ll have both /api/ and (deprecated) /solr > >>>>> In 8.x we’ll have only /api/ (?) > >>>>> > >>>>> If we then in e.g. 12.x want to introduce a v3 thing, we could map > it to > >>>>> /api/v3 and move it to /api/ in 13.x, with /api/v3 as an alias. > >>>>> We could even let users configure “v2RootPath” and “v3RootPath” at > will > >>>>> if they need to adapt to some client need and do not want to use a > reverse > >>>>> proxy for that. > >>>>> > >>>>> -- > >>>>> Jan Høydahl, search solution architect > >>>>> Cominvent AS - www.cominvent.com > >>>>> > >>>>> 3. jul. 2017 kl. 22.57 skrev Anshum Gupta <ans...@anshumgupta.net>: > >>>>> > >>>>> 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 > >>>>>>> > >>>>> > >> > > > > > > > > -- > > ----------------------------------------------------- > > Noble Paul > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
