I'm +1 to ensuring V2 APIs are ready by everyone's definition before 9.0.
Hence I'm +1 to treat it as a blocker. However, if others feel we shouldn't
hold it up, I'll likely not care about V2 APIs for another 2 years (by 10.x
timeframe).
On Thu, 28 Oct, 2021, 2:12 am Ishan Chattopadhyaya, <
ichattopadhy...@gmail.com> wrote:
> My main concern is if we don't put it out there as front and center and
> hence don't allow users to use it, what motivation does that leave for
> developers to continue working on it? If it is not fully ready, some of us
> don't want it to be out there prominently for users to use it. Hence, if I
> can't ensure my efforts will make it fully ready, what is my motivation to
> work on it? By making it default, we signal to users that this is the
> future and you should try it out. Though, it is experimental at the moment.
> Or, use older one, which will eventually be removed.
>
> On Thu, 28 Oct, 2021, 12:30 am Jason Gerlowski, <gerlowsk...@gmail.com>
> wrote:
>
>> > For whatever functionality is exposed via V2 APIs, it is ready.
>>
>> You lose me right around here Ishan. IMO exposing functionality makes
>> a particular V2 API "usable", it doesn't necessarily make it "ready".
>> "Ready" implies some confidence that I personally don't have without
>> our test randomization using v2 APIs, without Solr itself doing some
>> dogfooding in SolrJ and in the Admin UI, etc. Those are the biggest 3
>> gaps that I see personally. For me, "ready" comes down to: would I
>> recommend v2 to a client? And as it stands today with those gaps, I
>> personally wouldn't.
>>
>> > If there are critical gaps in V2, lets treat them as blockers before 9.0
>>
>> I don't relish the idea of holding up a looong awaited major release
>> on v2 API changes that a few volunteers are chipping away at in scant
>> personal time. I understand the rare opportunity that major releases
>> offer in terms of deprecation and code removal, and that it's tempting
>> for that reason. But it just doesn't seem realistic to me with
>> current momentum. Better to let the work progress as devs can do it,
>> than slamming the brakes on 9.0 for who knows how long. If people are
>> terribly bummed that v1-deprecation might miss 9.0, then we can always
>> consider a shorter 9.x dev cycle to get it deprecated and removed for
>> a quick 10.0.
>> ----
>>
>> There's been decent response, so an attempt to summarize:
>>
>> * (So far) everyone seems on board with some sort of designation of
>> v2's "evolving" status. (Jason, Eric, Gus, Ishan, Houston). Though
>> exactly what that should be ("experimental"? "beta"? etc) is
>> uncertain.
>> * (So far) there's broad support for relaxing backcompat (Jason, Eric,
>> Ishan, Houston). Though there was a concern about breaking existing
>> users (Gus).
>> ** An alternate suggestion was made to do a v3 API in order to
>> maintain v2 backcompat (Gus), though this raised concerns about
>> slowing down development or being a step back (Jason, Eric, Ishan)
>> * Mixed discussion on making v2 "default" for 9.0. Some in favor
>> (Ishan), some against (Jason, Houston).
>>
>> (If I've mischaracterized anything here, please correct.)
>>
>> On Wed, Oct 27, 2021 at 1:23 PM Eric Pugh
>> <ep...@opensourceconnections.com> wrote:
>> >
>> > I thought about fixing SOLR-14795 when I documented the v2 apis, and
>> the amount of change and the “ugh, it will be hard to have back
>> compatibility” led me to not trying to move any of the sub tickets forward.
>> >
>> > If the V2 version of the API’s is more open to change, then it would
>> make it easier for me to want to try and pick up some of these tickets.
>> >
>> > I think this is an example of why we might want to rethink what we
>> label v2 API’s ;-). Experimental or otherwise!
>> >
>> > On Oct 27, 2021, at 12:24 PM, Alexandre Rafalovitch <arafa...@gmail.com>
>> wrote:
>> >
>> > Hmm,
>> >
>> > My understanding was that V2 Config API is part of the V2 APIs and
>> > relevant discussion, so when the questions about gaps came up, I felt
>> > it was relevant. Perhaps it is less relevant than I thought. I will
>> > let others judge and apologize if I introduced too much noise.
>> >
>> > Regards,
>> > Alex.
>> >
>> > On Wed, 27 Oct 2021 at 12:04, Ishan Chattopadhyaya
>> > <ichattopadhy...@gmail.com> wrote:
>> >
>> >
>> > Alex, these seem to be issues with config API (and should be solved),
>> while this discussion is about v2 version of all APIs. What is the
>> relevance here?
>> >
>> > On Wed, 27 Oct, 2021, 9:24 pm Alexandre Rafalovitch, <
>> arafa...@gmail.com> wrote:
>> >
>> >
>> > I feel that the summary of my umbrella case (SOLR-14795) qualifies for
>> this:
>> >
>> > "
>> > General issues with output being materialized schema:
>> > * parameters have already been resolved and are not indicated
>> > * empty keys may not be output (e.g. dataDir)
>> > * default parameters will be output that are not in solrconfig.xml
>> > "
>> >
>> > This had failed to start the discussion at the time, but I feel that
>> > it should have, as Solr configuration without being able to specify
>> > and propagate the defaults implies a very different workflow.
>> >
>> > On Wed, 27 Oct 2021 at 11:34, Ishan Chattopadhyaya
>> > <ichattopadhy...@gmail.com> wrote:
>> >
>> >
>> > some aspects of the v2 API are clearly downgrades from the v1 API.
>> >
>> >
>> > Please open a JIRA, and we can discuss there. If there's already any
>> discussion, please point to them.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> > For additional commands, e-mail: dev-h...@solr.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> > For additional commands, e-mail: dev-h...@solr.apache.org
>> >
>> >
>> > _______________________
>> > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> > This e-mail and all contents, including attachments, is considered to
>> be Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>>
>>
