epugh commented on PR #975:
URL: https://github.com/apache/solr/pull/975#issuecomment-1241042225

   > Found a buried question from @dsmiley that I'd failed to answer:
   > 
   > > do you think your work here might be better characterized as a V3 API 
rather than changing V2? Of course we agreed to change V2 as we see fit but I'm 
just wondering if you are hampered by lots of code already existing for V2.
   > 
   > In some ways this work does _feel_ like a v3 effort. Particularly because 
we're integrating a new (to Solr) API framework. But from the user or 
API-consumer perspective I think this is "just" v2 hardening and refactoring. 
We're not introducing new APIs that will exist alongside their v2 counterparts, 
etc. So I personally tend to think of this work as "v2".
   > 
   > In terms of the development, the existing v2 code hasn't done too much 
"hampering". Of course, in terms of this specific PR, it's been a big pain to 
add JAX-RS support to V2HttpCall while still keeping the existing `Api` and 
introspect codepaths there working. But I don't see that being much of a 
problem on an api-by-api basis as we add new or convert existing endpoints over 
to JAX-RS.
   > 
   > > Lots of V2 classes could be marked Deprecated to communicate our intent 
to not take it into the future.
   > 
   > I'm all for deprecating some of the existing (but now legacy?) v2 
framework, especially: `Api`, `ApiBag`, `ApiSupport`, `Command`, `PayloadObj`, 
`AnnotatedApi`, etc.
   > 
   > I'd probably wait on adding those deprecations until we have a bit more 
history converting things over to JAX-RS, but in a few month's time I'd love to 
push up a PR for that. I don't want to put the "cart before the horse" there 
though.
   
   I'll chime in a bit too...   We did decide to mark V2 API's as experimental, 
so that we could free ourselves up to change them ;-).    


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to