+1 Perhaps it’s possible to use forbiddenapis to block new test classes explicitly calling v1 apis? (Look for “/solr/admin/.*”)? And of course make sure that SolrJ commands map to v2...
Jan Høydahl > 16. mai 2019 kl. 19:33 skrev David Smiley <david.w.smi...@gmail.com>: > > I'm concerned about Solr's V2 API and the maintenance burden of attempting to > maintain consistency with V1. For example upon looking through the release > notes and seeing a new exciting REINDEXCOLLECTION command (a V1 reference), I > see no corresponding adjustments in V2 -- > lucene-solr/solr/solrj/src/resources/apispec/* It's so easy for this to > fall out of sync. When working on a feature affecting admin API stuff I need > to somehow just remember/know and then ask myself if I want to test a new > feature with just one API or both. Ugh. Additionally, the vast majority of > our documentation is in V1, and our help in solr-user and elsewhere often > uses a one-liner URL to the V1 API as well. > > As if Solr needed more maintenance challenges than it has already (e.g. > tests). :-( > > I mainly want to point out this problem right now to see if others also see > the problem and if anyone else has thought about it. While working on Time > Routed Aliases, I saw it but didn't call it out. I thought maybe somehow our > implementation of the admin functionality could be done differently so as to > nearly require a V2 adjustment, and thus we don't forget. For example if the > V2 API was basically primary, and if it had metadata that described how a > virtual V1 API could work based off metadata in the V2 apispec there that > does mapping. In this way, everything would work in V2 and V1 by default, or > at least the majority of the time. V2 requires more information than V1, so > if we continue to have V1 primary (i.e. do nothing), V2 will always be > falling behind. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley
