> 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
<[email protected]> 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 <[email protected]>
> 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
> <[email protected]> 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, <[email protected]>
> 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
> <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
> _______________________
> 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: [email protected]
For additional commands, e-mail: [email protected]
