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 wrote:
> crea
created a blocker ticket
https://issues.apache.org/jira/browse/SOLR-11183
On Thu, Aug 3, 2017 at 10:23 AM, Noble Paul wrote:
> I shall open a ticket. let's resolve it there
>
> On Wed, Aug 2, 2017 at 5:30 AM, Jan Høydahl wrote:
>> Thanks for following up, Anshum. I'm on holiday so not much onlin
I shall open a ticket. let's resolve it there
On Wed, Aug 2, 2017 at 5:30 AM, Jan Høydahl 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. 2
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 :
>
> Bumping this up.
>
> Last call in case we want to change the endpoi
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 wrote:
> I meant /api in addition to /v2
>
> On Jul 4, 2017 16:17, "Noble Paul" wrote:
>
>> /api is ok. It takes a non trivial amount of time to make t
I meant /api in addition to /v2
On Jul 4, 2017 16:17, "Noble Paul" 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
/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" wrote:
> I’ll let this email thread run a little bit longer to
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 ap
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 wrote:
> +1 to not having v2. I don't have a personal preference between the
> suggestions by Shawn, and Jan, so lik
+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 wrote:
> Hi,
>
> Now that we’re getting used to thinking localhost:8983/v2/ as the new api
> entr
Hi Jan,
"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."
I think this makes a lot os sense now that you pointed it out.
+1 to what David suggested
On Mon, Jul 3, 2017 at 1:12 PM, Jan Hø
Thanks Shawn, David and Ishan. Don’t know how to interpret the silence. Does it
mean that the rest of you believe /v2/ is the best naming?
My intention is not to spark a discussion war, but to make sure there is
consensus on this before 7.0 release.
--
Jan Høydahl, search solution architect
Com
My concern with /api is that handling backcompats between versions (v2 to
v3 etc.) is problematic; and if we decide not to support backcompat, then
it could be a source of confusion for the user.
I'm +1 for /v2 or /api/v2 (and v3 etc. going forward).
On Fri, Jun 16, 2017 at 10:53 PM, David Smiley
+1 to remove the "v2" in the URL or make it an optional add-on (e.g. /api
or /api/v2). Any/all of the proposals by Jan & Shawn sound reasonable to
me.
On Fri, Jun 16, 2017 at 9:59 AM Jan Høydahl wrote:
> Hi,
>
> Now that we’re getting used to thinking localhost:8983/v2/ as the new api
> entry p
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
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 sneak
16 matches
Mail list logo
