+1 8x will be in bugfix-only mode after the 8.11 release, so v2 bugfixes are ok, but feel free to innovate and break back-compat in 9.x!
Jan > 8. nov. 2021 kl. 13:39 skrev Eric Pugh <[email protected]>: > > Jason G and I were chatting about if we need to back port to the 8X line > every change made to enhance the V2 APIs, and my thought was that part of the > “experimental” tag is that we could just work in the main code base. This > would make it easier to move quicker and not always have that “how is this > going to work in in 8X” question in the back of our minds... > > If we get to a point where we feel good about the API and want to do a back > port to some future 8X release we could, but that we shouldn’t feel > constrained to do that for every small improvement to every API. > > Thoughts? > > > >> On Nov 5, 2021, at 9:27 AM, Gus Heck <[email protected] >> <mailto:[email protected]>> wrote: >> >> Once I get the core-container split out into it's own >> provider/service/whatever started by a context listener, we should do v3 as >> a servlet giving us a clean slate, and easy access to verbs. I suspect v2 >> was made much more difficult by the fact that it had to co-exist with a lot >> of other code inside a filter. >> >> On Fri, Nov 5, 2021 at 6:04 AM Jan Høydahl <[email protected] >> <mailto:[email protected]>> wrote: >> +1 to experimental >> >> If we want to be more standards-based, embrace OpenAPI and perhaps more >> standardized RBAC frameworks, then I believe there will be a v3 API based on >> JAX-RS or something, with more active use of http verbs. >> While v2 is harder for devs to use and remember, it has somewhat better >> practices wrt no mutating state with GET requests, which is the worst thing >> about v1 imo. >> >> Even a v2 or v3 API can have some "convenience" things built-in. I.e. >> allowing common operations with a simple URL param rather than having to add >> a POST body for all. >> >> Jan >> >>> 5. nov. 2021 kl. 10:54 skrev Eric Pugh <[email protected] >>> <mailto:[email protected]>>: >>> >>> I can live with “experimental” ;-) >>> >>>> On Nov 4, 2021, at 6:42 PM, Shawn Heisey <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> On 11/4/21 1:20 PM, Jason Gerlowski wrote: >>>>> With that in mind, I think the next steps here should probably be to: >>>>> >>>>> 1. decide what label or term we want to go with ("evolving"? >>>>> "experimental"? "beta"?), and >>>>> 2. figure out what the best way to publicize change in policy. >>>>> >>>>> For (1) my vote is probably still "experimental". If others care >>>>> enough to chime in though I'm happy to go with whatever's most >>>>> popular. >>>> >>>> From what I have seen, an experimental designation is the right way to go >>>> for v2. If we don't do that, then I think we have to cease development on >>>> v2 and create something like v3, designating THAT as experimental. I >>>> don't see much value in coming up with a synonym that means the same thing. >>>> >>>>> Eric expressed some concern that "experimental" implies that v2 might >>>>> not get adopted. IMO that implication might not be a bad thing; >>>>> Houston is talking about making the APIs more RESTful, Tim wants to >>>>> add OpenAPI support, and there were lots of other changes suggested in >>>>> this thread alone. >>>> >>>> >>>> Also from what I have seen, v2 is not ready for adoption yet, so I think >>>> we call it experimental and get ready to really overhaul it. I believe I >>>> heard somebody say it's incomplete compared to the original API, plus the >>>> community has a lot of ideas about major additions and/or fundamental >>>> changes in its design. If we eat our own dog food by using the v2 API in >>>> things like SolrJ, scripts, and the admin UI, we are more likely to try >>>> and come up with stable designs that don't need to be thrown out >>>> frequently. The experimental designation would make it possible for us to >>>> throw something out and begin again if we find that the existing design of >>>> that component is too limiting. >>>> >>>> I would like to eventually (in 10.0, maybe) get to a point where we >>>> declare the original API as deprecated and remove the experimental >>>> designation from v2. At that point we only make new bells and whistles >>>> available in v2 ... and then a major version or two after that, we remove >>>> the old API entirely. Backward compatibility is an important goal to >>>> strive for, but it can't be maintained forever. >>>> >>>> This is possibly a pipe dream: I would like a new API to be able to do as >>>> much as possible with URL parameters, only REQUIRING a body on the request >>>> for things that are complex, or where a body is a natural pathway, like >>>> indexing. Of course it should also be possible to put EVERYTHING into the >>>> body and send no URL parameters at all. I think they call this wanting to >>>> have my cake and eat it too. :) Like I said ... might be a pipe dream. >>>> >>>> Something I have found to be invaluable is the fact that a LOT of things >>>> can be done and tested with the original API simply by typing a URL into a >>>> browser. If everything MUST be done with a request body, I would find >>>> that to be extremely inconvenient. If the community thinks that's the >>>> right thing to do, then I will adapt. It's not all that difficult to send >>>> a body with something like curl. And that requirement might make people >>>> more cautious about how they interact with Solr. >>>> >>>> Thanks, >>>> Shawn >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> <mailto:[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> <mailto:[email protected]> >>>> >>> >>> _______________________ >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >>> http://www.opensourceconnections.com >>> <http://www.opensourceconnections.com/> | My Free/Busy >>> <http://tinyurl.com/eric-cal> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >>> >>> 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. >>> >> >> >> >> -- >> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) >> http://www.the111shift.com <http://www.the111shift.com/> (play) > > _______________________ > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com <http://www.opensourceconnections.com/> > | My Free/Busy <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > 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. >
