You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Anshum Gupta <an...@anshumgupta.net> on 2017/08/01 18:32:21 UTC
Re: /v2 API -- will there ever be a /v3?
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 <no...@gmail.com> wrote:
> I meant /api in addition to /v2
>
> On Jul 4, 2017 16:17, "Noble Paul" <no...@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" <ja...@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 <an...@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 <an...@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 <ja...@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-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>
Re: /v2 API -- will there ever be a /v3?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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 <no...@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 <no...@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 <ja...@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 <an...@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 <no...@gmail.com>
> wrote:
> >>>
> >>> I meant /api in addition to /v2
> >>>
> >>> On Jul 4, 2017 16:17, "Noble Paul" <no...@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" <ja...@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 <an...@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 <an...@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 <ja...@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-unsubscribe@lucene.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>
> >>>>>
> >>
> >
> >
> >
> > --
> > -----------------------------------------------------
> > Noble Paul
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: /v2 API -- will there ever be a /v3?
Posted by Noble Paul <no...@gmail.com>.
created a blocker ticket
https://issues.apache.org/jira/browse/SOLR-11183
On Thu, Aug 3, 2017 at 10:23 AM, Noble Paul <no...@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 <ja...@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 <an...@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 <no...@gmail.com> wrote:
>>>
>>> I meant /api in addition to /v2
>>>
>>> On Jul 4, 2017 16:17, "Noble Paul" <no...@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" <ja...@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 <an...@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 <an...@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 <ja...@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-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>
>>>>>
>>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
--
-----------------------------------------------------
Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: /v2 API -- will there ever be a /v3?
Posted by Noble Paul <no...@gmail.com>.
I shall open a ticket. let's resolve it there
On Wed, Aug 2, 2017 at 5:30 AM, Jan Høydahl <ja...@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 <an...@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 <no...@gmail.com> wrote:
>>
>> I meant /api in addition to /v2
>>
>> On Jul 4, 2017 16:17, "Noble Paul" <no...@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" <ja...@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 <an...@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 <an...@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 <ja...@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>
>
--
-----------------------------------------------------
Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: /v2 API -- will there ever be a /v3?
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <an...@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 <no...@gmail.com> wrote:
>> I meant /api in addition to /v2
>>
>>> On Jul 4, 2017 16:17, "Noble Paul" <no...@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" <ja...@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 <an...@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 <an...@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 <ja...@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-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>
>>>>